패키지 구조 설계

계층형 패키지 구조

 

말 그대로 계층형으로 패키지를 설계하는 방식이다. 

엔티티(도메인)

• 상품
• 회원
• 주문
• 상품DTO
• 회원 DTO
• 주문 DTO

컨트롤러

• 상품 컨트롤러
• 회원 컨트롤러
• 주문 컨트롤러

서비스

• 상품 서비스
• 회원 서비스
• 주문 서비스

저장소

• 상품 저장소
• 회원 저장소
• 주문 저장소

 

계층형 구조는 전체적인 구조를 빠르게 파악할 수 있는 장점이 있지만 디렉터리에 클래스들이 너무 많이 모이게 된다는 단점이 존재한다.

 

 

 

 

도메인 패키지 구조

 

도메인 패키지 구조는 도메인 단위로 디렉토리를 구성한다.

domain

• 상품
  • 상품 엔티티(도메인 객체)
  • 상품 저장소
  • 상품 컨트롤러
  • 상품 서비스
  • 상품 DTO 등등
• 회원
  • 회원 엔티티(도메인 객체)
  • 회원 저장소
  • 회원 컨트롤러
  • 회원 서비스
  • 회원 DTO 등등
• 주문
  • 주문 엔티티(도메인 객체)
  • 주문 저장소
  • 주문 컨트롤러
  • 주문 서비스
  • 주문 DTO 등등

도메인 구조는 관련된 코드들이 응집해 있는 장점이 있지만, 프로젝트에 대한 이해도가 낮을 경우 전체적인 구조를 파악하기 어려운 점이 있다. 앞서 게시판 프로젝트의 패키지 구조 설계를 계층형으로 설계하였는데 클래스들이 많아지면 많아질 수록

도메인 구조로 설계하는 것이 훨씬 좋은 것 같다.

 

아래는 백기선님의 도메인 패키지 구조에 대한 답변이다.

 

 

또한 이번에 영한님의 MVC 2편 강의를 들으면서 도메인 구조 설계로 하되 domain과 web으로 디렉토리를 세분화하여 쪼개는 방식이 굉장히 좋은 패키지 구조 설계라고 생각이 들었다.

 

Domain과 Web으로 쪼개기

 

domain

• 상품
  • 상품 엔티티(도메인 객체)
  • 상품 저장소
  • 상품 서비스 등등
• 회원
  • 회원 엔티티(도메인 객체)
  • 회원 저장소
  • 회원 서비스

web

• 상품
  • 상품 컨트롤러
  • 상품 DTO 등등
• 회원
  • 회원 컨트롤러
  • 회원 DTO 등등

 

도메인은 화면, UI, 기술 인프라 등등의 영역은 제외한 시스템이 구현해야 하는 핵심 비즈니스 업무 영역을 말한다.

 

향후 web을 다른 기술로 바꾸어도 도메인은 그대로 유지할 수 있어야한다.

만약 API 서버로 변경하기 위해 컨트롤러를 변경해야한다면 domain은 손댈 필요없이 web 영역만 변경하면 된다.

이 방식을 사용하려면 web은 domain을 알고있지만 domain은 web을 모르도록 의존관계가 단방향으로 흐르게 설계하여야한다. 즉, web 패키지를 모두 삭제해도 domain에는 전혀 영향이 없도록 의존관계를 설정하는 것이다.

domain과 web 하위에서도 도메인 단위로 쪼개어 디렉토리를 구성하기 때문에 훨씬 더 유지보수나 클래스들을 관리하기에 편리하다.