[Project] 패키지 구조에 대한 고민과 해결

도메인별 계층형 패키지 구조 vs 계층별 도메인 패키지 구조

1. 도메인별 계층형 패기지 구조

• 장점
  • 모듈화와 단일 책임 원칙 강화: 각 도메인이 별도의 패키지로 분리되어 있기 때문에, 모듈화가 잘되어 있고 각 도메인은 자신의 역할과 책임에 집중할 수 있어 코드의 가독성과 유지보수성을 높임.
  • 확장성: 새로운 기능이나 변경이 필요할 때 해당 도메인 내의 특정 계층만 수정하여 다른 도메인에는 영향을 미치지 않으므로 시스템 전체의 일관성을 유지하면서도 개발자는 필요에 따라 독립적으로 도메인을 확장할 수 있음.
  • 테스트 용이성: 각 도메인이 독립적으로 관리되기 때문에 유닛 테스트나 통합 테스트가 각 도메인 단위로 쉽게 구성될 수 있음.
• 단점
  • 패키지 구조의 복잡성: 여러 도메인이 있고 각 도메인마다 여러 계층(controller, service, repository 등) 이 있는 경우 패키지 구조가 복잡해짐 초기 구축 시에는 문제가 되지 않지만 시간이 지날수록 관리와 이해가 어려워짐.

장점 요약: 모듈화와 단일 책임 원칙을 강화하여 가독성과 유지보수성 높고, 새로운 기능이나 변경 시 해당 도메인 내의 특정 계층만 수정하여 독립적으로 확장 및 테스트가 용이함.

 

2. 계층별 도메인 패키지 구조

• 장점
  • 단순한 구조와 직관성: 각 계층별로 패키지가 나눠져 있어 초기 구성이 간단하며, 작은 프로젝트나 기능이 단순한 경우에는 용이함.
  • 계층 간 협업 용이성: 특정 계층(controller, service 등)의 클래스들이 모여 있어 계층 간 협업이 강화되고, 특히 작은 팀이나 단일 도메인 프로젝트에 용이함.
• 단점
  • 유연성과 일관성 유지의 어려움: 새로운 기능이나 변경 사항이 발생할 경우, 해당 기능이 속한 모든 계층의 패키지를 수정해야 할 수 있어 시스템 전체의 일관성을 유지하기 위해 추가 작업이 필요할 수 있음을 의미함.
  • 모듈화의 한계: 각 도메인의 모듈화가 제한될 수 있으며, 도메인 간 중복된 코드나 비슷한 기능의 클래스가 계층별로 중복될 가능성 있음

장점 요약: 단순한 구조 덕분에 초기 구성이 간단하고, 계층 간 협업이 용이하여 작은 팀이나 단일 도메인 프로젝트에 적합함.

 

결론: 프로젝트의 요구사항에 따라 적절한 패키지 구조를 선택해야 하며, 대규모 시스템에는 도메인별 계층형 구조, 작은 프로젝트에는 계층별 도메인 구조가 적합합니다.

 

팀 선택: 가독성과 유지보수성, 새로운 기능 추가를 고려했을 때 도메인별 계층형 구조로 선택했습니다.

-- 도메인별 계층형 패키지 구조
com.bms
├── user
│   ├── book
│   │   ├── BookController.java       
│   │   ├── BookService.java        
│   │   ├── BookEntity.java          
│   │   ├── BookRepository.java      
│   │   └── BookDto.java             
│   ├── review
│   │   ├── ReviewController.java
│   │   ├── ReviewService.java       
│   │   ├── ReviewEntity.java        
│   │   ├── ReviewRepository.java
│   │   └── ReviewDto.java

-- 계층별 도메인 패키지 구조
com.bms
├── controller
│   ├── book
│   └── review
├── service
│   ├── book
│   └── review

추가적인 패키지 구조

• 클린 아키텍처의 원칙을 기반으로 하며, 각 계층마다 책임과 역할이 명확히 분리한 계층별 도메인 패키지 구조 방법입니다.

com.bms
├── application
│   ├── book
│   │   └── BookService.java         
│   ├── review
│   │   └── ReviewService.java      
├── domain
│   ├── book
│   │   ├── entity                  
│   │   │   └── BookEntity.java
│   │   ├── repository               
│   │   │   └── BookRepository.java
│   │   └── service                   
│   │       └── BookServiceImpl.java
│   └── review
│       ├── entity                   
│       │   └── ReviewEntity.java
│       ├── repository                
│       │   └── ReviewRepository.java
│       └── service                   
│           └── ReviewServiceImpl.java
└── presentation
    ├── book
    │   └── BookController.java      
    └── review
        └── ReviewController.java

각 계층별 설명

1. presentation 계층
   • 목적: 사용자 인터페이스와의 상호작용을 담당합니다.
   • 위치: HTTP 요청을 처리하고, 사용자에게 데이터를 반환하는 컨트롤러 클래스들이 위치합니다.
   • 예시: BookController.java, ReviewController.java 등이 있습니다.
2. application 계층
   • 목적: 비즈니스 로직의 실행을 조정하고, 도메인 객체들 간의 상호작용을 처리합니다.
   • 위치: 표현 계층과 도메인 계층 사이에서 데이터 전송 객체(DTO)를 사용하여 요청을 처리하고, 도메인 서비스 인터페이스를 호출합니다.
   • 예시: BookService.java, ReviewService.java 등이 있습니다.
3. domain 계층
   • 목적: 핵심 비즈니스 규칙을 담고 있는 도메인 객체들과 이를 영속화하는 리포지토리 인터페이스를 정의합니다.
   • 위치: 도메인 객체(Entity), 리포지토리 인터페이스(Repository)가 위치합니다. 서비스 인터페이스(Service)도 정의할 수 있지만, 구현 클래스는 application 계층에서 제공합니다.
   • 예시: BookEntity.java, BookRepository.java, ReviewEntity.java, ReviewRepository.java 등이 있습니다.
4. infra 계층 (선택적으로 추가할 수 있음)
   • 목적: 외부 시스템과의 연동, 데이터베이스와의 직접적인 상호작용을 처리합니다.
   • 위치: 데이터베이스 접근이나 외부 API 호출 등을 담당하는 클래스들이 위치할 수 있습니다.

주의사항

• 각 계층은 가능한 한 독립적이고 서로에게 종속되지 않도록 설계해야 합니다.
• 의존성 주입(Dependency Injection) 패턴을 사용하여 각 계층 간의 결합도를 낮추고 유지보수성을 높입니다.
• 각 계층의 역할과 책임을 명확히 정의하고, 이를 준수하여 코드를 작성하는 것이 중요합니다.

이러한 계층별 구조를 사용하면 소프트웨어 시스템의 유연성과 확장성을 높일 수 있으며, 코드의 구조가 명확하여 개발 및 유지보수가 용이해집니다.

 

끝.