DTO와 Entity는 Common에
모노레포에서의 DTO와 Entity 관리 방식
모노레포 구조에서
DTO와 Entity를 common 라이브러리에 두는 것은 일반적인 패턴입니다. 이 접근 방식은 특히 NestJS 모노레포에서 많이 사용됩니다.
일반적인 모노레포 구조의 장점
- 중앙 집중식 타입 관리:
- 모든 모듈이 참조할 수 있는 단일 소스로 작동
- 타입 정의의 중복을 방지하고 일관성 유지
- 마이크로서비스 전환 용이성:
- 서비스를 분리할 때도 공통 타입 정의는 그대로 유지
- 각 서비스는 동일한
@app/common패키지를 참조하여 일관성 유지
- GraphQL 스키마 통합:
- 여러 서비스의 GraphQL 스키마를 통합할 때 타입 충돌 방지
- 일관된 타입 시스템 유지
마이크로서비스로 전환 시 고려사항
서비스를 분리할 계획이 있다면:
- 공통 패키지 배포:
- common 라이브러리를 npm 패키지로 배포하여 각 서비스가 참조
- 또는 모노레포 구조를 유지하면서 서비스만 별도 배포
- 버전 관리:
- 공통 타입 변경 시 버전 관리를 통해 하위 호환성 유지
- 주요 변경사항은 모든 서비스에 동시에 적용
- 도메인별 분리 가능:
- 필요에 따라 common/dto/users, common/dto/products 등으로 도메인별 구분
- 서비스 분리 시 관련 타입만 가져갈 수 있도록 구조화
대안적 접근 방식
일부 팀은 다른 접근 방식을 선호하기도 합니다:
- 도메인 중심 구조:
apps/
├── users/
│ ├── src/
│ │ ├── dto/
│ │ └── entities/
├── products/
│ ├── src/
│ │ ├── dto/
│ │ └── entities/
- 하이브리드 접근법:
- 여러 서비스에서 공유되는 타입은 common에 배치
- 특정 서비스에만 사용되는 타입은 해당 서비스 내에 배치
결론
모노레포에서 DTO와 Entity를 common 라이브러리에 두는 것은 일반적이고 효과적인 방식입니다. 이 접근법은 코드 재사용성을 높이고 일관성을 유지하는 데 도움이 됩니다.
마이크로서비스로 전환할 계획이 있더라도, 공통 타입 정의를 중앙에서 관리하는 것은 여전히 유효한 전략입니다. 각 서비스는 동일한 타입 정의를 참조하여 일관성을 유지할 수 있습니다.
프로젝트의 규모와 요구사항에 따라 가장 적합한 접근 방식을 선택하는 것이 중요합니다.