DDD (Domain-Driven Design)란?

DDD (Domain-Driven Design)란?

DDD(Domain-Driven Design)는 소프트웨어 개발의 복잡성을 해결하기 위한 방법론 중 하나로, 2003년 Eric Evans가 제안한 개념이다. DDD는 소프트웨어를 개발할 때 "도메인(문제 영역)"에 대한 깊은 이해를 바탕으로, 소프트웨어 설계와 구현을 진행하는 철학 및 접근 방식이다.

도메인(Domain)이란, 특정 문제를 해결하거나 비즈니스 목표를 달성하는 데 필요한 지식, 규칙, 프로세스, 개념의 집합이다. DDD는 이러한 도메인에 중점을 두어, 소프트웨어가 실제 비즈니스 요구사항을 잘 반영할 수 있도록 설계하는 것이 핵심이다.

---

DDD의 핵심 개념

1. 도메인(Domain)
   • 소프트웨어가 해결하고자 하는 비즈니스 문제 또는 관심 영역을 말한다. 예를 들어, 온라인 쇼핑몰에서는 상품 관리, 주문 처리, 결제 시스템 등이 각각의 도메인에 해당한다.
2. 도메인 모델(Domain Model)
   • 도메인 모델은 도메인의 주요 개념과 그들 간의 관계를 추상화한 모델이다. 이는 소프트웨어 내에서 도메인을 표현하는 방식으로, 비즈니스 로직과 규칙을 반영한다.
   • 도메인 모델은 클래스 다이어그램이나 객체 모델 형태로 표현될 수 있으며, 소프트웨어의 설계 및 개발에 중요한 역할을 한다.
3. 유비쿼터스 언어(Ubiquitous Language)
   • 유비쿼터스 언어는 도메인 전문가와 개발자 간의 의사소통에서 사용하는 공통 언어이다. 도메인 전문가와 개발자가 같은 용어로 의사소통할 수 있도록 해주며, 혼동을 줄이고 설계와 구현 과정에서 일관성을 유지할 수 있게 한다.
   • 예를 들어, ‘고객’, ‘주문’, ‘결제’와 같은 용어들이 모두에게 동일한 의미로 통용되도록 한다.
4. 바운디드 컨텍스트(Bounded Context)
   • 바운디드 컨텍스트는 도메인 내에서 특정 개념이 사용되는 범위나 문맥을 정의한다. 하나의 용어가 다르게 해석될 수 있는 여러 상황에서, 각 용어가 어떤 문맥에서 어떤 의미로 사용되는지를 명확히 하기 위해 사용된다.
   • 예를 들어, ‘고객’이라는 개념이 영업부서에서는 ‘잠재 고객’일 수 있지만, 배송 부서에서는 ‘구매 완료된 고객’을 의미할 수 있다. 각 부서마다 다른 ‘바운디드 컨텍스트’를 정의하고, 해당 문맥에서만 용어를 사용하도록 한다.
5. 엔티티(Entity)
   • 엔티티는 고유한 식별자를 가지고 있으며, 생애 주기 동안 상태가 변경될 수 있는 도메인 객체이다. 예를 들어, ‘주문’은 고유한 주문 ID를 가진 엔티티이며, 주문 상태(예: 대기, 처리 중, 완료 등)가 변경될 수 있다.
6. 값 객체(Value Object)
   • 값 객체는 식별자가 없으며, 상태에 의해서만 구별되는 객체이다. 값 객체는 불변(immutable)으로 설계되는 경우가 많다. 예를 들어, ‘주소’는 값 객체일 수 있다. 같은 주소 정보(예: "서울시 강남구")는 동일한 값 객체로 취급될 수 있다.
7. 어그리게이트(Aggregate)
   • 어그리게이트(Aggregate)는 관련된 엔티티와 값 객체의 모음으로, 하나의 일관된 변경 단위로 다뤄진다. 어그리게이트에는 루트 엔티티(Root Entity)가 있으며, 모든 외부 접근은 루트 엔티티를 통해서만 이루어진다. 이로써 복잡한 도메인 객체 간의 관계를 관리하고, 변경의 일관성을 유지한다.
8. 리포지토리(Repository)
   • 리포지토리는 도메인 객체를 영속성 계층(예: 데이터베이스)에서 가져오고 저장하는 역할을 하는 인터페이스다. 개발자는 도메인 모델을 데이터베이스와 직접적으로 연결하는 대신, 리포지토리를 통해 도메인 모델을 처리한다.
9. 서비스(Service)
   • 도메인 서비스는 여러 엔티티와 값 객체를 포함한 비즈니스 로직을 처리하는 도메인 계층의 서비스이다. 이 서비스는 도메인 로직을 수행하지만, 상태를 가지지 않으며, 일반적으로 특정 비즈니스 로직을 수행하는 메서드의 집합이다.

---

DDD의 설계 패턴

1. 레이어드 아키텍처(Layered Architecture)
   • DDD는 주로 레이어드 아키텍처를 따른다. 이 아키텍처는 시스템을 여러 계층으로 분리하여 복잡성을 줄이고, 각 계층이 독립적으로 개발 및 유지보수될 수 있도록 한다.
   • 주요 계층은 다음과 같다.
     • 프레젠테이션 계층: 사용자 인터페이스(UI)와 관련된 계층.
     • 애플리케이션 계층: 사용자 요청을 처리하고, 비즈니스 로직을 호출하는 계층.
     • 도메인 계층: 도메인 모델과 비즈니스 로직이 위치하는 핵심 계층.
     • 인프라스트럭처 계층: 데이터베이스, 외부 시스템과의 통신을 담당하는 계층.
2. 도메인 이벤트(Domain Event)
   • 도메인 이벤트는 도메인 내에서 발생한 중요한 상태 변화나 비즈니스 사건을 나타낸다. 예를 들어, "주문이 완료됨"이라는 이벤트가 발생하면, 다른 시스템에서 이 이벤트를 감지하여 적절한 처리를 할 수 있다.
   • 도메인 이벤트를 사용하면 시스템 간의 의존성을 줄이고, 느슨한 결합을 구현할 수 있다.
3. 팩토리(Factory)
   • 팩토리는 복잡한 객체나 어그리게이트의 생성을 캡슐화하는 패턴이다. 객체 생성을 직접 수행하는 대신, 팩토리를 사용하여 복잡한 로직을 추상화하고, 도메인 모델 내의 생성 로직을 단순화한다.

---

DDD의 핵심 철학

1. 도메인에 대한 깊은 이해
   • DDD에서는 소프트웨어 개발에서 가장 중요한 것은 도메인에 대한 깊은 이해라고 강조한다. 개발자는 단순히 요구사항을 구현하는 데 그치지 않고, 도메인 전문가와 협업하여 비즈니스 문제를 근본적으로 해결할 수 있는 모델을 만들어야 한다.
2. 복잡성 관리
   • 소프트웨어가 다루는 문제는 종종 복잡하다. DDD는 이 복잡성을 바운디드 컨텍스트와 같은 개념을 통해 관리한다. 이를 통해 각 도메인을 독립적으로 처리하고, 시스템의 전체 복잡성을 줄일 수 있다.
3. 설계와 구현의 일치
   • DDD는 설계와 구현이 긴밀하게 연결되어야 한다고 본다. 설계한 도메인 모델은 그대로 코드로 구현되며, 비즈니스 요구사항이 변경되면 모델과 코드도 함께 변경되어야 한다.

---

DDD의 장점

1. 비즈니스와 소프트웨어의 일관성 유지
   • DDD는 도메인 전문가와 개발자가 동일한 언어(유비쿼터스 언어)를 사용하게 함으로써, 비즈니스 요구사항이 소프트웨어에 명확하게 반영될 수 있도록 한다. 이를 통해 비즈니스 요구사항 변화에 유연하게 대처할 수 있다.
2. 복잡한 도메인 문제 해결
   • DDD는 복잡한 비즈니스 로직을 효과적으로 모델링하고 관리하는 데 초점을 맞추기 때문에, 복잡한 도메인에서 특히 유용하다. 도메인 모델을 통해 복잡한 비즈니스 로직을 명확하게 구조화할 수 있다.
3. 유지보수성 향상
   • DDD는 시스템의 각 부분을 바운디드 컨텍스트로 나누고, 독립적으로 관리할 수 있도록 하여, 코드의 복잡성을 줄이고 유지보수성을 향상시킨다. 각 컨텍스트는 독립적으로 개발 및 배포될 수 있으며, 다른 컨텍스트에 영향을 주지 않으므로 시스템의 확장성과 유지보수가 용이하다.

---

DDD 적용 시 고려사항

1. 복잡한 도메인에 적합
   • DDD는 복잡한 도메인을 다루는 대규모 시스템에서 효과적이다. 비즈니스 로직이 복잡하거나, 여러 도메인 컨텍스트를 관리해야 하는 경우 DDD가 적합하다. 하지만 간단한 시스템에서는 오히려 불필요하게 복잡도를 증가시킬 수 있다.
2. 도메인 전문가와의 긴밀한 협업 필요
   • DDD는 도메인 전문가와의 긴밀한 협업을 전제로 한다. 도메인에 대한 깊은 이해 없이는 효과적으로 적용하기 어렵다.
3. 높은 초기 학습 곡선
   • DDD는 다양한 개념과 패턴을 포함하고 있어, 초기 학습이 다소 어렵고 시간 소요가 클 수 있다. 팀 전체가 DDD에 대한 이해를 공유하고, 함께 학습하는 것이 중요하다.

---

결론

DDD는 복잡한 도메인 문제를 해결하고 비즈니스 요구사항을 소프트웨어에 잘 반영하기 위한 강력한 방법론이다.

도메인 모델을 중심으로 한 개발 접근 방식은 비즈니스와 개발 간의 격차를 줄이고, 지속적으로 변화하는 요구사항에 효과적으로 대응할 수 있게 도와준다.