-
Notifications
You must be signed in to change notification settings - Fork 3
프로젝트 패키지 구조
Ryan Bae edited this page Jul 15, 2023
·
1 revision
- 우리 프로젝트는 Package by Layer 구조를 사용할 것임.
- project
- controller
- dto
- entity
- service
- repository
- 모듈화는 코드를 여러 모듈로 분리하는 프로세스임. 복잡성을 줄이는 것 외에도 시스템의 이해 가능성, 유지 관리 가능성 및 재사용 가능성을 높임.
- 패키지를 모듈화 하는 방법은 크게 두 가지가 있음: Layer, Feature
- 우아한형제들 기술이사는 프로젝트를 진행할 때마다 패키지 구조를 고민함. 큰 줄기에 해당하는 패턴은 있어도 정답은 없음. 프로젝트의 상황과 규모에 따라서 거기에 맞는 유지보수하고 확장하기 쉬운 구조가 있기 때문.
- 우수한 시스템 설계를 위해서는 패키지 내의 높은 응집력과 패키지 간의 낮은 결합이 필수적이다.
- 기능별 패키지는 마이크로서비스 아키텍처와 같음. 각 패키지는 특정 기능과 관련된 클래스로 제한됨.
- 레이어별 패키지는 모놀리식 아키텍처와 같음. 프로젝트의 크기가 커짐에 따라 클래스 수는 제한 없이 증가.
- 마틴 파울러가 제안한 것처럼 마이크로 서비스 아키텍처로 새 프로젝트를 시작하는 것은 좋은 생각이 아닐 수 있음. 애플리케이션이 크게 성장하고 한계가 확실하다면 그때 마이크로서비스 아키텍처로 마이그레이션 하는 것이 좋음.
서로 밀접하게 관련되지 않은 클래스가 포함되어 있기에 패키지 내 응집력은 package by feature 보다 낮음.
- Controller
- ProductController
- UserController
- entity
- Product
- User
- Dto
- ProductDto
- UserDto
- Service
- ProductService
- UserService
- Repository
- ProductRepository
- UserRepository
패키지 내에서는 응집도가 높고 패키지 간 결합도는 낮음.
- User
- UserController
- UserDto
- User
- UserService
- UserRepository
- Product
- ProductController
- ProductDto
- Product
- ProductService
- ProductRepository
너무 작은 프로젝트인 경우 하나의 파일에 모든걸 넣고 최대한 단순하게 처리함.
- project
프로젝트의 요구사항이 추가되면서 기능이 증가하면 이제 컨트롤러, dto, entity, 비즈니스 로직을 처리하는 Service등 패키지를 분할 하는게 이익을 가짐
- project
- controller
- dto
- entity
- service
- repository
프로젝트가 더 커져서 여러 도메인이 추가되면 도메인 단위로 상위 패키지 개념을 더 추가할 수 있음.단순히 블로그API를 제공하다가. 회원 기능이 추가되면 다음과 같이 될 수 있음.
- project
- blog
- controller
- dto
- entity
- service.
- repository
- member
- controller
- dto
- entity.
- service
- repository
블로그 컨트롤러에서 회원과 관련된 서비스를 자주 사용할 경우 엔티티들도 서로 연관관계가 생길 수 있음. 그러면 다음과 같은 구조로 변경할 수 있음.
- project
- entity
- Blog
- Member
- controller
- Blog
- Member
- service
- Blog
- Member
(...continue)
핵심은 프로젝트가 성장함에 따라 프로젝트 구조도 현재 상황에 맞추어 성장하고 변경할 수 있어야함. 변경 비용이 크지 않아야함.
- TBD