🍀 JPA 기반 DDD 설계 경험과 오버 엔지니어링 회고
문제 상황: 도메인 간 연관관계를 끊은 DDD 설계
처음 프로젝트를 시작할 당시, 도메인 주도 설계(DDD)의 개념에 영향을 받아 설계를 시작했습니다. 도메인 간의 직접적인 연관관계 매핑을 피하고, 모든 연관 객체는 ID 값을 통해 직접 조회하는 방식으로 설계했습니다. 이는 도메인 간의 결합도를 낮추고, 각 도메인을 독립적으로 구성하려는 의도였습니다.
또한, DDD의 장점 중 하나인 도메인 설계 중심의 유즈케이스 구성, 그리고 서비스 레이어의 단순화, 테스트의 용이성 등을 기대하며 구조를 구성했습니다.
하지만 프로젝트가 점점 구체화되면서 다음과 같은 문제점이 발생했습니다.
- 로직이 복잡하지 않은데도 도메인 구조가 과도하게 분산됨
- 각 도메인 간의 관계를 ID로만 연결하니 JPA의 장점인 연관관계 매핑 기능을 활용하지 못함
- 결국 서비스 레이어에서 repository를 지나치게 많이 주입하게 됨
- 테스트가 단순해지기보다는 오히려 mock 설정이 복잡해지고, 유닛/통합 경계가 모호해짐
해결 방향: 도메인 설계 방식 재고
🔍 다양한 해결 방법
| 시도 | 설명 | 장단점 |
|---|---|---|
| 1. 연관관계 매핑 도입 (JPA 방식 복귀) | @ManyToOne, @OneToMany 등 매핑을 도입 | ✅ 코드 간결, 쿼리 명확 / ❌ 연관 도메인 변경 시 영향 ↑ |
| 2. DDD와 연관 매핑의 절충안 | 도메인 내부는 ID 기반 유지하되 조회 시 DTO 혹은 서비스에서 join 처리 | ✅ 설계 유연성 확보 / ❌ 설계 복잡도는 여전 |
| 3. Aggregates 중심 구조 재정비 | 복잡한 도메인은 루트 기준으로 묶어 설계, 단순한 도메인은 연관 매핑 | ✅ 유연한 설계 가능 / ❌ 설계 기준을 일관되게 가져가기 어려움 |
| 4. Context 별 DB 접근 분리 | Bounded Context 별 Repository를 구분 → 진짜 독립된 도메인 설계 | ✅ 대규모 시스템 적합 / ❌ 작은 시스템엔 과함 |
DDD 방식에 대한 간단 정리
DDD (Domain-Driven Design) 은 "도메인 모델을 중심으로 비즈니스 로직을 설계"하고자 하는 접근입니다. 핵심 개념은 다음과 같습니다:
- Aggregate (집합체): 비즈니스에서 하나의 일관된 트랜잭션 단위를 가진 루트 엔티티
- Entity/Value Object: 식별 가능성과 값 기반 객체의 구분
- Repository/Service/Factory: 도메인 외부 책임 분리
- Bounded Context: 의미적으로 독립된 도메인 경계
이 개념은 복잡한 비즈니스 로직, 협업이 많은 대규모 시스템, 기능별 분리가 명확한 프로젝트에서 강력한 설계 도구가 됩니다.
오버 엔지니어링의 함정
하지만 현실적인 문제는 다음과 같습니다:
- 프로젝트의 비즈니스 로직이 단순할 경우, DDD는 설계만 무겁고 유지보수는 더 어려워질 수 있음
- 협업 구조가 단순하거나, 변화가 적은 도메인에서는 오히려 JPA 연관 매핑이 더 효율적임
- 테스트 코드가 단순해질 거라는 기대와 달리, 전략 패턴, 도메인 분리, ID 조회 설계 등으로 인해 테스트가 더 복잡해지는 경우가 많음
적절한 설계 방법과 기술 선택
다음은 실제 프로젝트 환경에서 고려해야 할 설계 기준입니다:
| 조건 | 적절한 설계/기술 |
|---|---|
| 복잡한 비즈니스 도메인, 팀 규모 큼 | ✅ DDD (Bounded Context, Aggregate Root 중심) |
| 단일인 개발, 기능 적음 | ✅ JPA 기본 설계, 연관관계 매핑 적극 활용 |
| 명확한 계층 설계 원함 | ✅ Service/Repository 기반 레이어 구조 |
| 도메인보다 데이터 흐름이 중심 | ✅ Transaction Script 패턴도 고려 가능 |
결론
설계는 목적에 종속된다.
도메인 주도 설계는 강력한 설계 도구이지만, 프로젝트의 성격, 팀 규모, 비즈니스 복잡도에 따라 그 활용 방식은 달라져야 합니다.
이번 프로젝트를 통해 얻은 교훈은 다음과 같습니다:
“DDD는 모든 프로젝트에 적합하지 않다.
설계는 문제를 해결해야 하며, 불필요한 복잡함을 가져와선 안 된다.”
결국 가장 중요한 것은, 문제를 해결할 수 있는 가장 단순하고 명확한 구조를 선택하는 것입니다.
설계보다 중요한 건 지속 가능한 개발입니다.
