도메인 주도 설계(DDD, Domain-Driven Design)는 단순한 방법론이 아닌 도메인 중심의 개발 접근법이다.
Intro
Nextstep 에서 진행하는 조영호님의 강의인 "도메인 주도 설계의 사실과 오해" 에서 배운 내용을 요약하고 정리한 부분이 포함되어 있다.
책으로 읽었던 내용들을 다시 정리할 수 있었던 부분들이 많았고, 개념정리를 다시 할 수 있어서 좋았는데, 개인적으로 적극 추천한다.
도메인 주도 설계의 본질
- 접근법
- DDD는 프로세스나 방법론이 아닌 패턴의 집합이며, 상황에 맞게 선택적으로 적용해야 한다.
- 모델링 사이클
- 도메인 모델 = 코드 모델 이며, 도메인이 바뀌면 코드도 바뀌고 그 반대도 성립한다.
- 구현 가이드
- 빌딩 블록을 통해 도메인의 개념을 코드로 옮기며 복잡도를 줄인다.
- 불변식 기반
- Aggregate 단위의 일관성을 유지하며, 도메인 규칙의 불변성을 코드로 보장한다.
엔티티 vs 값 객체
| 엔티티 (Entity) | 값 객체 (Value Object) |
|---|---|
| 식별성이 중요 | 속성이 중요 |
| 가변 (상태 변경 가능) | 불변 (상태 변경 불가) |
| 식별자로 동일성 비교 | 속성 값으로 동등성 비교 |
| 생명 주기 추적 필요 | 대체 가능 / 엔티티의 복잡성 감소 |
Entity
- 식별자 로 구분되며, 상태 변경이 가능하다.
- 생명 주기 관리가 필요하며, 동일성 비교가 중요하다.
Value Object
- 속성 이 중요하고, 불변성을 가진다.
- Entity 의 복잡성을 줄이는 역할을 수행한다.
- 값이 같으면 동일한 객체로 취급하며, 동등성 비교가 핵심이다.
상태 변경 로직은 Entity 에 집중시키고, 값을 Value Object 로 추출해 구조를 단순화하자.
어그리게이트 (Aggregate)
정의
- 여러 Entity 와 Value Object 를 하나로 묶는 단위 경계
- Aggregate 는 캡슐화 경계를 형성하며, 외부에서는 루트 엔티티만 참조 가능 트랜잭션
- Aggregate 단위로 처리 불변식
- 내부 도메인 상태의 일관성을 보장
루트 Entity 는 전역 식별성을 가지고 있고, 궁극적으로 불변식을 검사할 책임이 있다.
경계 안의 Entity 는 지역 식별성을 가지고 있으며, 외부에서는 무조건 루트 Entity 만 참조 가능하다.
리포지토리 (Repository)
역할
- Aggregate 단위로 영속성 을 관리하며, 데이터 저장 및 검색을 담당하다.
- DDD 에서는 원래는 Repository 는 컬렉션과 비슷한데, 메모리상에 객체가 있는 것처럼 쓰는 객체이지만 현대에는 Database 라고 보면 된다.
설계 원칙
- 객체 단위가 아닌 Aggregate 단위로 Repository 를 생성한다. (Aggregate 당 하나의 Repository)
- ID를 통해 외부에서 참조, 내부에서는 객체로 참조한다.
연관 관계 설계 원칙
- 도메인 중심의 행위 기반 모델링이 중요하며, 연관 관계는 최소화해야 유지보수성이 좋아진다.
- 양방향 참조는 복잡성을 증가시키므로 가급적이면 단방향으로 설계한다.
- 1대 N 관계는 지연 로딩 문제로 인해서 선호하지 않고, N대 1 관계를 선호한다.
- ID 참조를 통해 외부 참조를 최소화하고, Aggregate 내부에서는 객체 참조를 통해 탐색한다.
서비스 계층 구조
- 도메인 서비스: 도메인 로직이지만 Aggregate 에 넣기 애매한 로직 담당
- 애플리케이션 서비스: 비즈니스 흐름을 조합
- 인프라 서비스: 외부 시스템과 연결 (DB, MQ 등)
설계 접근법
- 책임 주도 설계 → 객체지향 사고를 기반으로 설계
- 계약에 의한 설계 → 불변식 을 기준으로 로직을 구성
DDD 적용 사이클 & 애자일과의 유사점
DDD 의 적용 흐름 사이클은 애자일 방법론과 매우 밀접하게 연관이 있는데, 두 접근법 모두 반복적이고 점진적인 개선을 중요시 한다는 특성이 있다.
반복적 개발
- 한 번에 완벽한 시스템을 구축하기 보다는 반복적인 사이클 을 통해 점진적 으로 시스템을 발전 시키는 접근법이다.
지속적인 피드백
- 애자일에서 중요시하는 지속적인 피드백 루프가 DDD 의 테스트 - 리팩토팅 - 도메인 분석 순환과 유사하다.
협업 중심
- 애자일은 개발자와 이해관계자 간의 긴밀한 협업을 강조하고, DDD 는 도메인 전문가와 개발자 간의 지식 공유와 협업이 핵심이다.
변화 수용
- 애자일과 DDD 모두 요구사항과 이해의 변화를 자연스럽게 수용하는 프레임워크를 제공한다고 볼 수 있다.
점진적 모델 개선
- 애자일의 점진적 개발 방식은 DDD 에서 도메인 모델을 점진적으로 발견하고 개선해 나가는 과정과 동일하다고 볼 수 있다.
DDD의 핵심 가치
도메인 중심 설계는 일관성을 유지하며, 시스템을 명확하게 분할할 수 있도록 돕는다.
💡 실용적인 적용 Tips
- 정형화 강박 금지: 상황에 따라 유연하게 모델링
- 초기 VO 모델링 → Entity로 승격
- 반복적 개선을 전제로 설계
정리
✔ DDD 는 복잡한 도메인을 코드로 명확하게 표현하기 위한 사고방식이다.
✔ 도메인 모델과 코드 모델의 일관성 유지, 불변식 보장, 행위 중심 모델링이 핵심이며, 패턴을 무조건 따르기보단 상황에 맞는 유연한 적용이 중요하다.
→ 오버엔지니어링을 경계 해야 한다.