DDD(Domain-Driven Design) 도메인 주도 설계란?

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

 

내 생각에 모든 아키텍처는 "낮은 결합도와 높은 응집도"라는 과학적 사고에 기초해 나온거라고 생각한다.

 

최근 많은 IT 기업에서 적용하고 있는 MSA에 관심을 갖던 중 DDD 라는 개념을 알게 되었고 마이크로 서비스의 도출기법으로 활용되는 DDD (Domain-Driven Design)에 대해서 간략히... 포스팅하려고 한다.

 

이 방법론은 복잡한 도메인 모델을 잘 이해하고, 그것을 구현할 수 있는 소프트웨어 모델을 만드는 것을 목표로 하며 이를 통해 개발자와 도메인 전문가가 협업하여 비즈니스 요구사항을 이해하고, 구현하는 과정에서 발생할 수 있는 문제를 최소화 할 수 있다.

 

도메인 주도 설계의 목적

 

도메인 주도 설계의 목적은 소프트웨어의 복잡성을 최소화하고 소통이 원활하게 이루어지고 요구사항을 효과적으로 쉽게 반영할 수 있게 한다.

---

👉 DDD의 구성요소

 

DDD는 크게 다음과 같은 구성요소를 가지고 있다.

 

1. Entity

 

Entity는 고유한 식별자를 가지며, 그 식별자를 통해 도메인 모델 내에서 유일하게 식별될 수 있는 객체이다. Entity는 비즈니스 규칙을 포함하며, 이를 통해 도메인의 실체 개념(모델)을 표현한다.

예를 들어, 고객, 주문, 상품 등이 Entity의 예시이다.

 

 

2. Value Object

 

Value Object는 고유한 식별자를 가지지 않으며, 도메인 모델 내에서 서로 다른 Value Object인 경우 그 값이 같다면 동일한 객체로 취급된다. 

• 도메인 내의 어떤 대상을 측정하고, 수량화하고, 설명한다.
• 관련 특징을 모은 필수 단위로 개념적 전체를 모델링한다.
• 일단 생성되면 변경할 수 없다.
• 항상 equals() 메서드를 오버라이드할 것을 권고한다.

예를 들어, 주소나 시간, 금액 등은 Value Object의 예시이다.

 

 

3. Aggregate

 

Aggregate는 Entity와 Value Object의 모음으로, 도메인 모델을 표현하는 데 있어 중요한 개념이다. Aggregate는 일종의 루트(Entity)를 가지며, 루트를 기준으로 Aggregate에 속하는 다른 Entity나 Value Object를 관리한다.

 

 

4. Repository

 

Repository는 Aggregate를 저장하고 검색할 수 있는 인터페이스를 제공하며 도메인 모델과 데이터 베이스 간의 매핑 역할을 한다.

 

 

5. Service

 

Service는 여러 Aggregate와 관련된 비즈니스 로직을 수행한다. 예를 들어, 주문과 결제 간의 관계를 처리하는 것은 Service이다.

 

 

6. Domain Event

 

Domain Event는 도메인 모델에서 발생하는 사건을 나타내는 개념이다. 예를 들어, 주문이 생성되거나 상태가 변경될 때 발생하는 이벤트는 Domain Event의 예시이다.

---

DDD를 적용한 소프트웨어 개발 방법

DDD를 적용한 소프트웨어 개발 방법은 크게 세 가지로 나눌 수 있다.

 

1. 팀 구성

 

DDD에서는 도메인 전문가와 개발자가 함께 일하는 것이 매우 중요하다. 도메인 전문가는 비즈니스 도메인에 대한 지식을 가지고 있으며, 개발자는 소프트웨어 개발에 대한 전문 지식을 가지고 있다. 두 집단이 협업하여 유비쿼터스 언어를 공유하고, 도메인 모델링을 통해 비즈니스 로직을 개발한다.

 

 

2. 도메인 모델링

 

DDD에서는 도메인 모델링이 매우 중요하며 이를 통해 비즈니스 도메인의 복잡성을 이해하고 모델을 만든다. 도메인 모델링은 요구사항을 이해하고 비즈니스 로직을 구현하기 위한 핵심 작업이다.

 

 

3. Aggregate 구현

 

애그리게이트는 도메인 객체들의 집합체이다. Aggregate(애그리게이트)는 도메인 모델링을 통해 구현되며 이는 하나의 Root Entitiy(루트 엔티티)를 가지며, Root Entity는 Aggregate 내의 다른 객체들을 관리한다. Aggregate를 구현할 때는 도메인 모델링을 기반으로 구성하며 Aggregate간의 결합도를 낮추는 것이 중요하다.

 

---

마무리

 

DDD는 복잡한 비즈니스 도메인을 다루기 위한 설계 원칙과 방법론이다. 개발자들은 이를 바탕으로 소프트웨어를 설계하고 개발하면서 비즈니스 로직을 효과적으로 구현할 수 있으며 소프트웨어의 유지보수성을 높이고 개발 생산성을 높일 수 있다. 

 

DDD는 비즈니스 로직을 도메인 모델 내에 포함시킴으로써, 비즈니스 요구사항을 쉽게 이해하고 구현할 수 있도록 도와주는 장점이 있으며 모델 기반의 설계를 강조하므로 기존에 존재하던 코드를 재사용하거나 수정하는 것 보다 새로운 코드를 작성하는 것이 용이하며 이를 통해 코드의 유지보수성과 확장성을 높일 수 있다.

 

또한, DDD는 테스트 용이성을 증가시킨다. 비즈니스 로직이 모델에 포함되어 있기 때문에, 테스트 코드를 작성할 때 비즈니스 규칙을 직접 참조하여 테스트 케이스를 작성할 수 있다. 이를 통해 코드의 품질을 높일 수 있다.

 

하지만, DDD는 고도의 전문 지식과 노력이 필요하며 도메인 전문가와 개발자가 협력하여 도메인 모델을 설계하고 그것을 구현하는 것은 어렵고 복잡한 일이다. 또한, DDD를 적용하는 것이 항상 최선의 선택은 아니며, 프로젝트의 규모나 복잡도에 따라 적용 여부를 결정해야 한다.

 

따라서 DDD를 적용하기 전에 프로젝트의 규모와 복잡도, 개발자들의 전문 지식 등을 고려하여 적용 여부를 결정해야 한다.