DDD (Domain Driven Design)

DDD = 도메인 주도 설계

소프트웨어를 이해하고 프로젝트를 성공적으로 완성하기 위한 사고방식

 

※ Domain 

사전적 의미 = 영역, 집합

개발 영역 = 일반적인 요구 사항, 소프트웨어로 해결해야 할 문제의 영역

 

등장 배경

기존의 애플리케이션 설계가 비즈니스 도메인에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 반성에서 출발

 

목적 및 특징

• 기존의 협업에서 IT로의 일방향 소통구조를 탈피하여 현업과 IT의 쌍방향 커뮤니케이션을 매우 중요하게 생각
• 비즈니스를 도메인 별로 나누어 설계하여 확장성을 고려했으며 모듈 간의 의존성은 최소화, 응집성은 최대화
• 소프트웨어의 복잡성을 최소화
• 복잡한 도메인을 해결하는 것을 높은 우선순위로 생각해 서비스를 만들어 내는 방법
  • 도메인의 복잡성을 조금 더 쉽게 다룰 수 있게 도와주는 도구
• 도메인과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식

 

도메인 모델

• 도메인에 대한 구체적인 설계, 도메인을 개념적으로 표현한 것
• 개념들의 관계를 표현한 모델
• 문제 영역을 시각화
• ex - 다이어그램, 그림 등

 

 

Strategic Design - 전략적 설계

도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어(보편 언어)를 통해 도메인 지식을 공유 및 이해하고 이를 기준으로 개념과 경계를 식별해 도메인 영역의 경계(바운디드 컨텍스트, bounded context)를 정의하고 경계의 관계를 컨텍스 맵(context map)으로 정의하는 활동

 

• 바운디드 컨텍스트는 여러개의 서브 도메인으로 구성되고 하나의 서브 도메인은 한 바운디드 컨텍스트에 포함됨
• 컨텍스트 간의 관계는 선으로 표현, U는 Upstream : 공급자, D는 Downstream : 수요자, 즉 데이터가 흐르는 방향
• 관계는 단방향으로 설정
• 동기 호출은 실선, 비동기 호출은 점선

 

 

Tactical Design - 전술적 설계

전략적 설계에서 도출된 바운디드 컨텍스트와 도메인을 이용하여 애그리거트 패턴, 엔티티와 값 객체 등의 도메인 모델링 구성 요소들을 구성하고 구현하는 활동

1. 엔티티 (Entity)

• 다른 엔티티와 구별할 수 있는 식별자를 가진 도메인의 실제 개념을 표현하는 객체
• 식별자는 고유하되 엔티티의 속성 및 상태는 계속 변할 수 있음
• 식별자가 있기 때문에 데이터베이스로 추적 가능

2. 값 객체 (Value Object)

• 각 속성이 개별적으로 변화하지 않는 개념적 완전성을 모델링
• 도메인 내의 어떤 대상을 측정하고, 수량화하고, 설명한다

3. 애그리거트 (Aggregate)

• 엔티티들을 대표하는 추상화된 객체
• 수많은 객체를 애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있음
• 애그리거트에 속한 객체는 유사하거나 동일한 라이프 사이클을 갖는다
• 애그리거트는 응집력을 유지하고 애그리거트 간에는 느슨한 결합을 유지한다

 

4. 팩토리 (Factory)

• 애그리거트의 생성 처리를 담당

5. 리포지토리(Repository)

• 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의
• 리포지토리는 애그리거트 단위로 존재( 애그리거트 1개 당 리포지토리 1개)

6. 도메인서비스

• 도메인 영역에 위치한 도메인 로직을 표현할 때 사용

 

 

DDD의 핵심은 도메인을 서비스 별로 분리하는 것

DDD를 프로젝트에 반영하기 위해서는 기술보다 도메인이 더 높은 우선순위를 가져야 하고, 어떤 문제를 해결하기 위해서는 항상 도메인을 먼저 고민하는 것이 필요

도메인들을 바탕으로 설계(Design)하고 프로젝트에 지속/반복적으로 반영하여 개발(Development) 해야 한다.