도메인 주도 설계 (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?”