[tecobrary server api v2] Layered Arcitecture - milzipmoza-developers/tecobrary-wiki GitHub Wiki

해당 설계는 패키지 의존성의 복잡도가 높다는 피드백을 받았습니다. 설계 개선을 높은 우선 순위로 가져가도록 합니다.

Tecobrary Server Api V2 의 계층 구조

기본적으로 Presentation Layer, Application Layer, Domain Layer, Infrastructure Layer 로 4-tier architecture pattern 으로 구조화 되어 있습니다.

Presentation Layer (UI Layer)

• 모든 Controller, ControllerAdivce 가 속하는 레이어 입니다.

Application Layer (Service Layer)

• 모든 Service 객체들이 속하는 레이어 입니다.

Domain Layer (Business Logic Layer)

• 모든 도메인 애그리거트의 객체들이 속하는 레이어 입니다.
• 어떤 객체의 모든 동작은 루트 애그리거트 객체를 통해 이루어 집니다.

Infrastructure Layer

• 외부의 API 를 이용하거나 Database, Authentication 과 관련된 레이어 입니다.
• Database 의 경우 해당 프로젝트에서는 Hibernate 를 이용하기 때문에 큰 로직이 포함되어 있지 않습니다.
• Authentication 의 경우 해당 프로젝트에서는 Jwt Token 발급, 인가 로직을 모두 구현하기 때문에 포함되어 있습니다.

프로젝트 계층 구조도

구글 프레젠테이션 링크에서 슬라이드로도 확인이 가능합니다.

개괄

레벨2 미니 프로젝트를 진행하면서 서비스 객체가 복잡해지는 것을 보고 고안한 설계 입니다. 더 좋은 설계가 있다면 현재 구조를 리팩토링하는 비용과 설계의 장점을 비교하여 플러스 되는 경우 리팩토링을 진행합니다.

• 모든 Repository 객체와 레포지토리의 기본적인 동작을 구현하는 기본적인 Service 객체가 1대 1 관계로 존재합니다.
• 모든 Controller 객체와 Service 객체는 1대 1 관계로 존재합니다.
• Application Layer 의 Service 객체는 다음과 같이 두 종류로 분류할 수 있습니다.
  • Repository 의 기본 동작을 구현하는 기본적인 Service 객체 (아래 그림의 B 그룹)
  • Controller 가 사용하는 Service 객체 (아래 그림의 A 그룹)
• A 그룹의 Service와 B 그룹의 Service는 1대 n 관계를 가집니다.

도메인 별 계층 구조도

User

LibraryBook

Serial

WishBook

RentHistory