도메인 주도 설계 (DDD, Domain Driven Design)

1. 도메인 주도 설계의 개념 및 원리

(1) 도메인 주도 설계(DDD, Domain Driven Design)의 개념

  • 소프트웨어 코드 구조와 언어를 비즈니스 도메인의 용어와 일치하도록 Model Driven Design 및 Ubiquitous Language 기반 도메인 모델 생성 후 코드를 구현하는 도메인 중심 개발 방법론

(2) 도메인 주도 설계의 원리

Model Driven DesignUbiquitous Language
– 모델 기반 분석/설계/구현 통합 및 개선
– 코드 구조와 용어는 도메인 모델 기반
– 리팩토링을 통한 모델-코드 간극 제거
– 도메인 전문가와 개발자 간 동일 언어 의사소통
– 직접적인 의소소통 수단 적극 활용
– 용어 변경 시 모델 및 코드 변경으로 간주

 

2. 도메인 주도 설계의 도메인 모델 패턴 및 구성요소

(1) 도메인 주도 설계의 도메인 모델 패턴

(2) 도메인 주도 설계의 구성요소

구분구성요소역할
계층 구조User Interface사용자 요청을 하위 계층에 전달
ApplicationApp 상태관리, Biz처리는 도메인에 요청
DomainDomain 정보 및 상태 포함 Biz. Logic 제공
Infrastructure다른 계층 지원 라이브러리 영속성 구현
구현 패턴Entity식별자를 가지며 영속성이 필요한 객체
Value Object식별자 없이 복제하여 사용, 영속성 불필요
ServiceEntity 등 여러 객체에서 발생하는 행위 담당
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?”

 

콘텐츠 사용 시 출처 표기 부탁 드리고, 댓글은 큰 힘이 됩니다^^