Layered Architecture

프로젝트 레이어 구성

참고

• spring-boot-clean-architecture

Tier 와 Layer의 용어 구분

Tier는 코드 또는 프로세스가 실행되는 물리적 단위(서버), Layer는 코드를 구성하는 논리적 단위(MVC)를 뜻한다.

Layered Architecture

• 레이어드 아키텍처는 일반적으로 4개의 레이어로 설명하고 있으며 각 레이어는 모듈 간에 구성 요소를 연결한다.
• 레이어 간 응집성을 높이고 의존도를 낮추기 위한 방법

레이어드 아키텍처의 규칙

• 상위 계층이 하위 계층을 호출하는 단방향성을 유지
• 상위 계층은 하위의 여러 계층을 모두 알 필요 없이 바로 밑의 근접 계층만 활용
• 상위 계층이 하위 계층에 영향을 받지 않도록 구성
• 하위 계층은 자신을 사용하는 상위 계층을 알지 못하게 구성
• 계층 간의 호출은 인터페이스를 통해 호출하는 것이 바람직하다.

각 레이어드의 관심사

• Presentation Layer의 관심사
  • 화면 표현 및 전환 처리
• Business Layer
  • 비즈니스 개념 및 규칙, 흐름 제어
• Database Layer
  • 데이터의 처리

추가적인 생각 및 참고

계속 개발을 하다보니 비즈니스 레이어에서 단순하게 도메인 로직 처리 후 결과 값을 반환하기도 하고, 2개 이상의 도메인 로직이 비즈니스 기능을 처리한 뒤에 값을 반환하기도 했다.

동일한 도메인 로직을 호출하는 여러 비즈니스 레이어가 존재하여 중복되는 코드를 제거하기 위해서 단일 도메인에 대한 처리만 담당하는 도메인서비스라는 레이어를 새롭게 정의하고 비즈니스 레이어에서는 도메인 서비스를 통해서 데이터를 요청하게끔 수정하였다.

• Persistence Layer: 도메인 객체(JPA Entity), 단일 도메인 관련 로직 (Domain Service)
• Business Layer: 비즈니스 기능을 구현하기 위한 로직(Service)
• Presentation Layer: API 제공 및 세션 관리, 유효성 검사

레이어 아키텍처의 주의사항 (도메인 주도 설게로 시작하는 마이크로서비스 개발)

해당 글에서 이야기하는 레이어에서는 엔티티로 들어갈 수록 레벨이 높아지며, 바깥으로 벗어날 수록 레벨 수준이 낮아진다. 내부 레이어는 비즈니스에 필요한 만큼 많은 수준을 가질 수 있으나, 항상 종속성 규칙을 고려해야 한다. 더 높은 수준은 더 낮은 수준에 의존해서는 안된다.

DAO를 인터페이스와 구현부로 분리해야 하는 이유 (토비의 스프링3)

• 데이터 액세스 로직을 담은 코드를 성격이 다른 코드에서 분리해 놓기 위함
• 분리된 DAO는 전략 패턴을 적용해 구현 방법을 변경해서 사용할 수 있게 만들기 위해서 이기도 하다.
• DAO를 사용하는 쪽에서는 DAO의 내부에서 어떤 데이터 액세스 기술을 사용하는지 신경쓰지 않아도 된다.
• 결국 DAO는 인터페이스를 사용해 구체적인 클래스 정보와 구현 방법을 감추고, DI를 통해 제공되도록 만드는 것이 바람직하다.

여기서는 Repository 레이어에 대한 분리에 대해서 적용할 수 있다.