2022년 9월 18일
도메인 주도 설계 (DDD, Domain Driven Design)
1. 도메인 주도 설계의 개념 및 원리
(1) 도메인 주도 설계(DDD, Domain Driven Design)의 개념
- 소프트웨어 코드 구조와 언어를 비즈니스 도메인의 용어와 일치하도록 Model Driven Design 및 Ubiquitous Language 기반 도메인 모델 생성 후 코드를 구현하는 도메인 중심 개발 방법론
(2) 도메인 주도 설계의 원리
Model Driven Design | Ubiquitous Language |
---|---|
– 모델 기반 분석/설계/구현 통합 및 개선 – 코드 구조와 용어는 도메인 모델 기반 – 리팩토링을 통한 모델-코드 간극 제거 | – 도메인 전문가와 개발자 간 동일 언어 의사소통 – 직접적인 의소소통 수단 적극 활용 – 용어 변경 시 모델 및 코드 변경으로 간주 |
2. 도메인 주도 설계의 도메인 모델 패턴 및 구성요소
(1) 도메인 주도 설계의 도메인 모델 패턴
(2) 도메인 주도 설계의 구성요소
구분 | 구성요소 | 역할 |
---|---|---|
계층 구조 | User Interface | 사용자 요청을 하위 계층에 전달 |
Application | App 상태관리, Biz처리는 도메인에 요청 | |
Domain | Domain 정보 및 상태 포함 Biz. Logic 제공 | |
Infrastructure | 다른 계층 지원 라이브러리 영속성 구현 | |
구현 패턴 | Entity | 식별자를 가지며 영속성이 필요한 객체 |
Value Object | 식별자 없이 복제하여 사용, 영속성 불필요 | |
Service | Entity 등 여러 객체에서 발생하는 행위 담당 | |
Aggregation | 객체 소유권과 경계 정의, 외부 접근 창구(root) | |
Factory | 객체 생성의 절차 캡슐화 | |
Repository | 객체 저장 담당, 객체 참조 로직 캡슐화 | |
모델 관리 | Module | 낮은 결합도, 높은 응집도 구현 |
Refactoring | 코드 및 모델 리팩토링, 설계영역 재검토 |
3. 도메인 주도 설계의 장/단점
도메인 주도 설계의 장점 | 도메인 주도 설계의 단점 |
---|---|
– S/W Life-Cycle 동안 용이한 커뮤니케이션 – 모듈화/캡슐화 기반 유연성 향상 – 현재 상황에 적합한 S/W 개발 | – 도메인 전문가 참여 필수 요구 – 기존 도메인의 관행 개선 어려움 – 기술적으로 복잡한 프로젝트에 부적합 |
- DDD 기반 프로젝트는 직관적인 도메인 연관관계로 명확한 설계 및 기능 구현이 가능하나, 도메인 전문성이 필수이며 프로젝트가 도메인에 종속되어 개선이 어려울 수 있으므로 도메인 전문가와의 적극적인 소통을 통해 효과적인 프로젝트 진행 필요
[참고]
- airbrake.io, “Domain-Driven Design: What is it and how do you use it?”