계층형 vs 도메인형
계층형 아키텍처 (Layered Architecture)
- 소프트웨어 시스템을 기능별로 계층화하여 구성하는 방식
- 각 계층은 특정한 책임을 가짐
com.example.project
├── controller (Presentation Layer)
├── service (Application Layer)
├── domain (Domain Layer)
└── repository (Infrastructure Layer)
- Presentation Layer (표현 계층): 사용자 인터페이스와 관련된 모든 요소를 포함 → controller
- Application Layer (애플리케이션 계층): 비즈니스 로직을 수행하고, Presentation Layer와 Domain Layer 간의 인터페이스 역할 → service
- Domain Layer (도메인 계층): 애플리케이션의 핵심 비즈니스 로직과 규칙을 처리 → entity, dto 등의 domain
- Infrastructure Layer (인프라 계층): 데이터베이스, 메시징 시스템 등 외부 시스템과의 통신을 처리 → repository
장점
- 분리된 관심사: 각 계층이 특정한 역할을 가지므로, 코드가 더 구조적이고 이해하기 쉬움
- 유지보수성: 각 계층이 독립적이기 때문에 특정 계층의 변경이 다른 계층에 미치는 영향을 최소화
- 재사용성: 일반적으로 하위 계층(예: 도메인, 인프라)은 상위 계층에서 재사용 가능
단점
- 복잡성: 각 계층을 지나서 호출이 이루어지므로, 간단한 작업도 여러 계층을 거쳐야 할 수도 있음
- 성능 저하: 계층 간의 지나친 분리가 성능 저하 가능성
- 도메인별 응집도 낮음: 비즈니스 로직이 여러 계층에 흩어질 수 있어, 특정 기능을 이해하거나 변경하는 데 어려움 있을 수 있음
도메인형 아키텍처 (Domain-Oriented Architecture)
- 애플리케이션을 도메인 또는 비즈니스 기능에 따라 패키지화하는 방식
- 계층형 아키텍처와는 달리, 시스템을 기능적으로 나누어 설계
- 특히 도메인 주도 설계(Domain-Driven Design, DDD)와 관련 깊음
com.example.project
├── order
│ ├── controller
│ ├── service
│ ├── domain
│ └── repository
├── customer
│ ├── controller
│ ├── service
│ ├── domain
│ └── repository
└── product
├── controller
├── service
├── domain
└── repository
장점
- 비즈니스 중심: 시스템의 구조가 비즈니스 도메인과 직접적으로 일치하므로, 비즈니스 로직을 이해하고 변경하는 것이 더 쉬워짐
- 유연성: 새로운 비즈니스 기능을 추가하거나 변경할 때, 해당 도메인에만 영향을 미치므로 더 유연하게 대처가능
- 독립적 개발: 각 도메인이 독립적이기 때문에, 팀 간의 충돌 없이 병렬로 개발가능
단점
- 코드 중복: 여러 도메인에서 비슷한 기능이 필요할 경우, 코드 중복이 발생 가능성
- 복잡성 증가: 도메인 경계를 잘못 설정하면 오히려 복잡성이 증가 가능성
- 초기 설계 어려움: 도메인을 잘못 설계하면, 시스템 전체의 유지보수가 어려워질 수 있음
