도메인 로직을 미리 분리하고 Top-Down 방식으로 설계
적용 상황
- 도메인이 명확하게 정의되어 있고, 요구사항이 충분히 분석된 경우
- 복잡한 비즈니스 로직이 많은 시스템에서 도메인 중심 설계가 필요한 경우
장점
- 초기 단계에서 도메인 모델의 일관성과 명확성을 확보
- 핵심 비즈니스 로직이 도메인 계층에 명확히 표현되어 팀 간 의사소통이 용이
단점
- 초기 설계에 많은 시간 소요
- 요구사항 변화에 민감하며, 리팩토링 비용이 높아질 가능성
기능별 설계 후 도메인 서비스로 추출 (Bottom-Up 접근)
적용 상황
- 애플리케이션 초기 개발 단계에서 도메인 경계가 불분명하거나, 빠른 프로토타이핑이 필요한 경우
- 비즈니스 로직이 간단하고 기능 완성도가 우선인 경우
장점
- 초기 개발 속도가 빠름
- 요구사항 변화에 따라 점진적으로 리팩토링 가능
단점
- 도메인 모델의 일관성과 통합이 늦어질 가능성
- 로직 분리가 늦어지면 유지보수성이 저하될 위험
실무에서의 Best Practice
혼합 방식 (Top-Down + Bottom-Up) 권장
- 핵심 도메인 로직과 주요 도메인 객체는 초기에 설계(Top-Down)
- 주변부 도메인 및 비즈니스 로직은 기능 개발 후 점진적으로 리팩토링(Bottom-Up)
도메인 서비스 도출 시점
- 중복 로직이 발생하거나, 엔티티의 책임이 과도해졌다고 판단될 때
- 복잡한 트랜잭션이나 비즈니스 규칙이 도메인 객체에서 처리하기 어려울 때
실무 팁
- Ubiquitous Language를 사용해 팀원들과 도메인 모델을 지속적으로 정교화
- 요구사항이 불명확할 경우, MVP(Minimum Viable Product) 접근 후 점진적으로 도메인 리팩토링
- 도메인 로직이 애플리케이션 로직(service 계층)과 섞이지 않도록 코드 리뷰와 리팩토링을 꾸준히 수행
.jpg)
Software Engineer