DDD(Domain Driven Design)

Yun·2024년 5월 19일

개인공부

목록 보기

17/28

DDD(Domain-Driven Design, 도메인 주도 설계)는 소프트웨어 프로젝트 개발 과정에서 도메인을 중심으로 시스템을 구축하는 방법론이다.

기존의 설계가 기술 중심이라면, DDD는 프로젝트를 Domain 단위로 나누어 설계한다.

DDD의 핵심적인 목표는 느슨한 의존도, 높은 응집도(Loose Coupling, High Cohesion)이다.

큰 큐모의 서비스를 작은 비즈니스 단위로 쪼개어 각 도메인 간의 응집도를 높이고 서로 다른 도메인끼리는 느슨한 의존도를 가지게 한다.

주요 원리는 다음과 같다.

~~사람이 쉽게 식별할 수 있도록 문자로 만든 인터넷주소~~ 가 아님!

DDD에서 도메인이란, 소프트웨어로 해결하고자 하는 비즈니스 문제 영역을 의미한다.

DDD는 크게 Strategic Design(전략적 설계)과 Tactical Design(전술적 설계)로 나눌 수 있다.

두 방식은 서로 보완적인 관계에 있으며, 추상화 수준과 적용 범위에 차이점이 있다.

시스템의 전체 구조와 경계를 정의하는 고차원적 접근 방식이다. 복잡한 도메인을 여러 Bounded Context로 분할하고, 이러한 Context 간의 관계를 관리한다.

시스템의 전체적인 구조를 이해하고, 각 부분이 어떻게 상호작용하는지 정의한다. 도메인의 복잡성을 관리하고 다른 시스템 간의 의존성을 최소화하는데 집중한다.

Ubiquitous Language는 프로젝트 팀 전체가 사용하는 공통 언어를 의미한다. 개발자, 디자이너, 비즈니스 전문가 등 프로젝트에 참여하는 모든 사람이 도메인의 복잡성을 이해하고 명확하게 소통하기 위해 사용된다.

핵심은 코드, 사용자 인터페이스, 문서 등 프로젝트의 모든 측면에서 일관된 용어와 개념을 사용하는 것이다. 의사소통 과정에서의 혼란을 줄이고 효과적인 설계 결정을 내릴 수 있다.

Bounded Context는 도메인 모델이 적용되는 경계를 명확히 하는 개념이다. 각각의 Bounded Context는 독립적으로 모델링되어야 한다.

모델 간의 충돌을 방지하고, 시스템 내에서 모델의 의미를 명확하게 한다.

Context Map은 Bounded Context 간의 관계를 나타내는 도구이다. 각 컨텍스트가 어떻게 상호작용하는지를 설명하며, 의존성과 통합 방법을 명확히 할 수 있다.

Strategic Design에서 정의한 Bounded Context 내에서 구체적인 모델링과 설계 기법을 적용하는 저차원적 접근 방식이다. 엔티티, 값 객체, 애그리거트, 도메인 이벤트, 도메인 서비스 등으로 복잡한 도메인 문제를 해결한다.

도메인 모델을 효과적으로 구현하여, 비즈니스 요구 사항을 정확하게 충족하는 것을 목표로 한다.

엔티티는 고유한 식별자를 가진 도메인 객체이다. 사용자 계정이나 주문 등의 개념이 엔티티에 해당된다.

값 객체는 하나의 완전한 단위로서 식별자를 가지지 않는다. 주로 엔티티의 속성을 설명하는 데 사용되며 불변한다. 주소, 돈, 날짜 범위 등의 개념이 값 객체에 해당된다.

애그리거트는 연관된 객체를 하나의 단위로 묶어서 관리하는 개념이다. 루트root 엔티티를 통해 모든 외부 접근을 관리하며, 집합체 내의 일관성을 유지하는데 중점을 둔다.

애거리거트를 이용해 복잡한 객체 간의 관계를 더 명확히 표현하고, 유지보수성과 확장성을 높일 수 있다.

도메인, 즉 소프트웨어가 해결하려는 실제 문제 영역에 초점을 맞춘다. 비즈니스 요구 사항을 더 정확하게 이해하고 반영할 수 있다.
복잡한 도메인을 이해하기 쉬운 모델로 추상화하여 모델링한다. 모델링이 소프트웨어 설계의 기반이 되며, 개발 과정에서 유비쿼터스 언어를 사용하여 모든 이해관계자가 동일한 용어로 의사소통할 수 있게 한다.
도메인을 여러 하위 도메인으로 나누고, 각 하위 도메인을 바운디드 컨텍스트로 관리한다. 시스템의 각 부분을 독립적으로 개발하고 관리하며, 서비스 간의 결합도를 최소화하여 유연성과 확장성을 높일 수 있다.

다양한 개념과 패턴을 포함하고 있어 제대로 이해하고 적용하기 어렵다. 도메인 전문가와 개발자 간의 긴밀한 협력이 요구된다.
복잡도가 낮은 프로젝트, 짧은 기간 내에 결과물을 요구하는 프로젝트에 적합하지 않다. 도메인 모델링에 상당한 시간을 투자해야 하며, 프로젝트 규모에 따라 불필요하게 복잡한 설계로 이어질 수 있다.