[개발 일기] 2025.06.05 - 새로운 패키지 구조

💡 개요

 

오늘은 “도메인 주도 개발 시작하기” 서적에서 본 새로운 패키기 구조에 대해 정리해 보자.

 

 

 

🛠️ 패키지 구조

 

아래 구조는 내가 옛날부터 사용해 오던 방식이다.

 

- member
  - controller
  - service
  - repository
- product
  - controller
  - service
  - repository
- order
  - controller
  - service
  - repository

 

 

 

 

서적에서 제안하는 패키지 구조는 다음과 같다.

 

- member
  - controller
  - application
      - ...Service (비즈니스 유스케이스 담당)
  - domain
      - ...Repository (Spring Data JPA 기준 인터페이스만 존재)
      - entity
          - valueObject (선택적으로 세분화)
      - domainService (도메인 로직 복잡 시 사용)
  - infra (선택적으로 구현체나 외부 연동 처리)

 

 

이 구조의 장점은 역할분리가 확실하고, 도메인 모델 중심 설계에 익숙해질 수 있다.

 

 

그리고 application과 domain 계층이 구분되기 때문에 핵심 비즈니스 로직과 도메인 관련 로직을 분리할 수 있다.

 

 

application 계층은 유스케이스(비즈니스 흐름)를 정의하며, 여러 도메인을 조합하거나 외부 서비스, 트랜잭션을 조절하는 역할을 담당하는 등 "도메인을 사용해서 실제 서비스 시나리오를 구현하는 계층"이다.

 

 

domain 계층은 순수한 도메인 모델(Entity, Value Object, Domain Service)을 포함하며, 도메인 자체의 규칙과 불변 조건 등 "도메인 내부의 순수한 로직"만을 다룬다.

 

 

이 계층은 다른 도메인이나 외부 시스템에 의존하지 않는다.

 

 

이렇듯, 두 계층의 역할이 확실하게 분리되기 때문에 각 클래스의 응집도를 높일 수 있다.

 

 

 

🤔 결론

 

요즘 구조나 패키지명, 변수명, 클래스명, 메서드명 이런 걸 ChatGPT에게 가장 많이 물어본다..

 

이 변수명 어때?? 이 메서드명은 로직에 적합할까? 이 구조는 어떤 것 같아?

 

 

이런 질문은 사소해 보이지만 코드 전체의 품질과 가독성을 결정짓는 요소들이기 때문에, 여러 개발 서적에서도 중요하게 다루고 있고, 지속적으로 고민해도 괜찮은 부분인 것 같다.