12/9 - TIL : DDD 란?

 

DDD는 Domain-Driven Design이다. 

 

| Domain

Domain이 무엇일까? 

 

DDD의 Domain은 비즈니스 Domain이다. 

• 비즈니스 Domain은 유사한 작업 그룹이다. 
• ex. 주문 도메인 : 주문 생성, 주문 취소, 주문 상태 확인, ... 등 
• 애플리케이션은 비즈니스 Domain 별로 나누어 개발될 수 있다. 
  
  • Domain은 애플리케이션이 해결하려고 하는 문제 영역을 의미하기 때문이다. 

 

| DDD 

따라서, DDD는 비즈니스 Domain 별로 나누어 설계하는 방식이다. 

 

DDD의 핵심은 결합도를 낮추고, 응집도를 높이는 것이다. (객체 지향의 핵심 목표와 일치하는 것을 알 수 있다.)

 

DDD의 핵심 설계 원칙은 다음과 같다. 

• 도메인을 중심으로 설계 : 도메인 문제 해결에 초점이 있다. 
• 도메인 전문가와의 협력 
• 도메인 로직 캡슐화 : 비즈니스 규칙을 도메인 모델 내부에 구현하여 코드와 비즈니스의 일관성을 유지한다. 
• 모듈화 및 경계 정의 : 시스템을 바운디드 컨텍스트로 나눈다. 

DDD에서 사용되는 개념도 알아보자. 

• 도메인 모델 : 비즈니스 도메인의 개념, 규칙, 데이터를 추상화한 모델이다. 도메인 모델이 시스템의 핵심 구조와 비즈니스 로직을 정의한다. 
• 유비쿼터스 언어 : 개발자와 도메인 전문가가 공유하는 공통 언어로, 도메인 모델의 개념과 용어를 일관되게 사용한다. 
• 바운디드 컨텍스트(Bounded Context) : 도메인이 적용되는 특정한 경계를 정의하는 것이다. 시스템 내에서 도메인 모델의 적용 범위를 명확하게 한다. 바운디드 컨텍스트를 통해 도메인 모델의 경계를 명확히 하고, 모델 간의 충돌을 방지한다. 
• 애그리거트(Aggregate) : 도메인 모델 내에서 일관성을 유지해야 하는 데이터와 객체의 집합이다. 
  • 도메인의 중요한 비즈니스 규칙을 하나로 묶은 것 
  • 애그리게이트의 진입점은 루트 엔티티로, 외부는 루트 엔티티를 통해서만 애그리게이트에 접근할 수 있다. 
  • 하위의 3개의 요소로 구성되어 있다. 
  • 엔티티(Entity): 고유 식별자를 가지며 상태가 변경되는 객체.
  • 값 객체(Value Object): 상태 변경이 없고, 값으로 동등성을 판단하는 객체(엔티티와는 다르게 고유 식별자가 없기 때문이다.).
  • 도메인 이벤트(Domain Event): 애그리게이트 상태 변경 시 발생하는 이벤트.

 

DDD를 적용하는 순서에는 대략적으로 다음과 같다.

1. 도메인, 서브 도메인, 바운디드 컨텍스트 정의하기 
2. Aggregate, Entity, Value Object, Repository 구현하기 
3. 적합한 아키텍처 결정하기 

 

객체 지향을 추구하면서 개발을 하다보면 자연스럽게 받아들여질 수 있는 개념이라고도 생각한다. 🧐