[TIL] 230619 <Spring> 소프트웨어 아키텍처에서의 패키지 구조 설계 방식

 

계층형 vs 도메인형

 

 

계층형 아키텍처 (Layered Architecture)

 

• 소프트웨어 시스템을 기능별로 계층화하여 구성하는 방식
• 각 계층은 특정한 책임을 가짐

 

com.example.project
├── controller  (Presentation Layer)
├── service     (Application Layer)
├── domain      (Domain Layer)
└── repository  (Infrastructure Layer)

 

1. Presentation Layer (표현 계층): 사용자 인터페이스와 관련된 모든 요소를 포함 → controller
2. Application Layer (애플리케이션 계층): 비즈니스 로직을 수행하고, Presentation Layer와 Domain Layer 간의 인터페이스 역할 → service
3. Domain Layer (도메인 계층): 애플리케이션의 핵심 비즈니스 로직과 규칙을 처리 → entity, dto 등의 domain
4. 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

 

장점

• 비즈니스 중심: 시스템의 구조가 비즈니스 도메인과 직접적으로 일치하므로, 비즈니스 로직을 이해하고 변경하는 것이 더 쉬워짐
• 유연성: 새로운 비즈니스 기능을 추가하거나 변경할 때, 해당 도메인에만 영향을 미치므로 더 유연하게 대처가능
• 독립적 개발: 각 도메인이 독립적이기 때문에, 팀 간의 충돌 없이 병렬로 개발가능

단점

• 코드 중복: 여러 도메인에서 비슷한 기능이 필요할 경우, 코드 중복이 발생 가능성
• 복잡성 증가: 도메인 경계를 잘못 설정하면 오히려 복잡성이 증가 가능성
• 초기 설계 어려움: 도메인을 잘못 설계하면, 시스템 전체의 유지보수가 어려워질 수 있음