...
JPA Entity 분리:
JPA Entity는Domain에 포함될 수 있지만, 데이터베이스 중심 설계와 도메인 중심 설계를 분리하려면Adapter의Persistence디렉터리에 위치시킬 수 있습니다.Repository와 Port 연결:
JPA Repository는Outbound Port의 구현체로 위치하며, 도메인 서비스에서 Repository 인터페이스만 의존하도록 설계합니다.Entity Listener 및 이벤트:
JPA의@EntityListeners를 활용하여 영속성 관련 이벤트를 처리할 수 있습니다.Specification 사용:
복잡한 쿼리를 작성해야 하는 경우, JPA의Specification또는Criteria API를 별도의 클래스로 구성해 Repository 로직을 깔끔하게 유지합니다.
Feature 기반 분리 시 주요 원칙
Feature 단위로 독립성 유지
각 Feature는 자신의 도메인 모델, 애플리케이션 로직, 데이터 저장소를 독립적으로 관리.
다른 Feature와의 통신은 API나 메시지 큐를 통해 수행.
공통 기능 최소화
각 Feature에서 중복을 줄이기 위해 공통 모듈(
common또는shared)을 생성할 수 있지만, 남용하지 않도록 주의.예: 공통 유틸리티, 인증/인가 모듈.
도메인 중심 설계
각 Feature는 자신의 도메인과 유스케이스에 맞는 설계를 유지.
다른 Feature에 의존하지 않도록 설계.
...
Feature 기반 구조 예시
| Code Block |
|---|
src
├── feature-a
│ ├── adapter
│ │ ├── api
│ │ ├── persistence
│ │ └── messaging
│ ├── application
│ │ ├── service
│ │ └── usecase
│ ├── domain
│ │ ├── entity
│ │ ├── valueobject
│ │ └── service
│ ├── dto
│ ├── port
│ │ ├── inbound
│ │ └── outbound
│ ├── configuration
│ ├── event
│ ├── exception
│ ├── mapper
│ ├── utils
│ └── test
├── feature-b
│ ├── adapter
│ ├── application
│ ├── domain
│ ├── dto
│ ├── port
│ ├── configuration
│ └── test
├── common (공통 모듈)
│ ├── security
│ ├── messaging
│ ├── exception
│ ├── utils
│ └── test
└── shared (공유 리소스)
├── api-clients
├── shared-entity
├── shared-dto
└── event
|
...
구체적인 분리 전략
Feature 간 통신
동기 통신: REST API 또는 gRPC를 사용.
비동기 통신: Kafka, RabbitMQ와 같은 메시지 브로커를 사용.
Feature 내부 구조
각 Feature는 완전한 헥사고날 아키텍처를 유지.
adapter,application,domain,port로 구성하여 독립성을 보장.
공통 코드 관리
공통 코드는
common디렉터리에서 관리.각 Feature가 필요에 따라 가져다 사용.
테스트 분리
단위 테스트는 Feature 내에서 진행.
통합 테스트는 Feature 간의 상호작용을 확인.
데이터베이스 분리
가능한 경우 각 Feature가 별도의 데이터베이스를 관리(MSA의 원칙).
동일한 데이터베이스를 사용해야 한다면, 데이터 접근은
Repository를 통해 제한.
...
MSA 최적화를 위한 추가 팁
API Gateway
외부 요청은 API Gateway를 통해 라우팅.
각 Feature는 내부적으로 독립적으로 동작.
Feature별 배포
각 Feature는 독립적으로 빌드 및 배포 가능하도록 설계.
Docker, Kubernetes를 활용.
모니터링과 로깅
각 Feature의 상태를 중앙에서 모니터링.
로그는 통합된 시스템(예: ELK 스택)에서 관리.