1. 계층형 구조
controller
⎿ ProductController
⎿ MemberController
service
⎿ ProductService
⎿ MemberService
domain
⎿ Product
⎿ Member
...- 애플리케이션에서 사용하는 계층별로 패키지를 구성하는 방법
- Layered Architecture의 컴포넌트 및 관련 요소들이 패키지가 되는 경우가 많음
장점
-
프로젝트에 대한 이해도가 상대적으로 낮아도 패키지 구조만 보고 전체적인 구조를 파악할 수 있음
- ex) 비즈니스 로직 파악 > Service 패키지 확인
-
계층별 응집도가 높아짐
- 계층별로 수정 사항이 발생할 때, 하나의 패키지만 보면 됨
단점
-
모듈 단위로 분리 시 어려움이 있음
-
도메인별 응집도가 낮음
- 도메인의 흐름을 파악하기가 어려움
- 특정 도메인의 로직을 확인하고 싶을 때는, 모든 계층 패키지를 확인해야 함
- 도메인 수정 사항이 발생했을 때, 여러 패키지에 대해 수정사항을 반영 시켜야 함
-
규모가 커질 때는 패키지가 복잡해져서 구분이 어려워짐
2. 도메인형 구조
product
⎿ controller
⎿ service
...
member
⎿ controller
⎿ service
...- 도메인을 기준으로 패키지를 나눈 구조
장점
-
모듈 단위로 분리하기 좋음
-
도메인별 응집도가 높아짐
- 특정 도메인의 로직을 확인하고 싶을 때는 하나의 패키지만 확인하면 됨
- 도메인 관련 수정 사항이 발생했을 때 변경 범위가 적음
-
유스케이스별로 세분화해서 표현 가능
- 상품 등록 유스 케이스 : RegisterProductService
- 상품 검색 유스 케이스 : SearchProductService
- 도메인별로 패키지가 나뉘기 때문에 위와 같은 네이밍으로 분리가 가능해짐
단점
-
애플리케이션의 전반적인 흐름을 한눈에 파악하기 어려움
- 따라서 프로젝트에 대한 이해도가 상대적으로 낮을 경우 전체적인 구조 파악이 어려움
-
어떤 도메인 패키지에 위치시킬지 명확하지 않을 경우 개발자별로 도메인을 구분하는 기준이 다를 수 있음
- 예상과 다른 패키지에 존재하는 경우 찾는 것에 어려움이 있을 수 있음
-
패키지 간에 순환 참조가 발생할 수 있음
- 모듈별로 구분이 되어 있기 때문에 같은 패키지에 존재해도되는 파일임에도 만약 다른 패키지에 존재를 하게 된다면 서로를 참조하는 순환 참조가 발생할 수 있음
💡 계층형 vs 도메인형
계층형 구조를 선택하는 경우
- 규모가 작고 도메인의 개수가 적은 경우
- 복잡도가 낮고 제공하는 기능이 적어서 하나의 계층에 속하는 클래스 수가 적은 경우
- 제공하는 기능을 명확하게 분리하기 어려운 경우
- 모듈별로 분리할 일이 없는 작은 규모의 프로젝트일 경우
도메인형 구조를 선택하는 경우
- 규모가 크고, 도메인의 개수가 많은 경우
- 복잡도가 높고 제공하는 기능이 많아서 하나의 계층에 속하는 클래스 수가 많을 경우
- 제공하는 기능을 명확한 기준으로 분리할 수 있는 경우
- 모듈별로 별도 서비스로 나눠질 가능성이 있는 규모의 프로젝트일 경우
✨ 상황에 맞는 구조를 선택하는 것! 정답은 없다! ✨
Backend development