DDD(Domain Driven Design)란?

📒 DDD(Domain Driven Design)

✔ 도메인을 중심으로 나누어 설계하는 디자인 방법론이다. 

◼ 도메인의 모델과 로직에 집중한다.

◼ 단일화된, 보편화된(통일화된) 언어를 사용한다.

◼ 분석 모델과 설계, 개발 모델의 개념이 일치한다.

 

💥 DDD의 탄생 배경

◼ DDD가 나오게 된 이유는 설계자와 개발자 둘 사이의 언어 장벽을 해결하기 위함으로, 설계자와 개발자 모두 도메인 관점에서 문제를 바라보게 하기 위해서이다.

◼ 복잡한 도메인 문제를 해결하고 유지보수 가능한 소프트웨어를 만들기 위해서 고안되었다.

 

💥 Domain이란?

사전적으로 '영역', '집합'을 의미하고, 실질적으로는 우리가 소프트웨어로 해결하고자 하는 문제의 영역을 의미한다.

예를 들어, 온라인 음식 주문이라는 문제를 소프트웨어로 해결하고자 한다면, '온라인 음식 주문'은 도메인에 해당된다. 또한, 한 도메인은 다시 하위 도메인으로 나눌 수 있는데, 이 경우에서는 결제, 배송, 정산, 카탈로그 등의 하위 도메인을 가질 수 있다.

 

💥 Domain Model

특정 도메인을 개념적으로 표현한 것으로, 기획이나 디자인, 개발할 때 의사소통의 목적으로 사용된다.

 

📒 Domain Layer

애플리케이션을 설계할 때, 다음과 같이 4가지 영역으로 분리될 수 있다.

◼ Presentation Layer: 표현의 영역으로, UI나 사용자의 요청을 받아 Application 영역으로 전달하고 처리 결과를 다시 사용자에게 보여주는 역할을 한다. (Controller)

◼ Application Layer: 응용의 영역으로, 시스템이 사용자에게 제공할 기능을 구현한다. (Service)

◼ Domain Layer: 도메인의 영역으로 도메인 모델을 구현한다. (사용자, 게시판...)

◼ Infrastructure Layer: 구현 기술의 영역으로, 구현 기술에 대한 것을 다룬다. (데이터 베이스, 외부 API...)

 

❗ DDD와 관련된 영역은 Domain Layer이며, 도메인 영역은 도메인을 구현한다. 예를 들어, 사용자 도메인인 경우 사용자 비밀번호 변경, 사용자 정보 변경 등의 기능들을 Domain 내에서 구현한다.

 

📒 DDD의 중요 개념

✔ Bounded Context 

서비스를 독립적으로 구현했을 때, 문제가 없이 돌아가는 영역, 즉 도메인 모델이 작동하는 컨텍스트를 명시하는 것

하나의 판매 사이트를 만들 때, 기능 영역들을 다음과 같이 구분할 수 있다.

User, 컨텐츠 제작, 예약 및 알림, 인증, 메타 정보 관리, 정산, 3rd Party, 판매, 통계...

다양한 영역들을 가지고 분류하여 서로의 의존성을 줄이기 위해 경계를 구성하고, 경계를 바탕으로 서비스로 나눌 수 있다. 위 상황에서는 다음과 같이 분리할 수 있다.

User, 인증, 3rd Party, 컨텐츠 제작 + 메타 정보 관리 + 판매, 예약 및 알림, 정산 + 통계

✔ Context Map

Bounded Context 간의 관계를 보여준다.

✔ Aggregate 

연관된 Entity와 Value Object의 묶음으로, 명령을 수행하기 위해 함께 조회하고 업데이트 해야 하는 단위이다.

연관된 객체들을 묶어서 하나의 단일한 개념으로 다루는 패턴이다.

 

❗ 같은 Aggregate에 속하는 상황

주문과 주문 아이템은 모두 주문 시점에 생성되고 업데이트 되므로 같은 Aggregate에 속한다.

 

❗ 다른 Aggregate에 속하는 상황

상품 정보와 사용자 리뷰는 다른 Aggregate에 속한다. 상품 정보를 변경하는 주체와 사용자 리뷰를 변경하는 주체가 다르고 서로의 변경이 서로에게 영향을 주지 않기 때문이다.

 

✔ Root Aggregate

접근하기 위한 최상위 객체로, Root Aggregate가 Aggregate의 생명 주기를 관리하며, 다른 엔티티들은 루트 엔티티와 강한 관계를 가지며 루트 엔티티 없이는 존재할 수 없다.

다음과 같은 상황에서 OrderItem에 접근하려면 반드시 Order를 통해서 접근해야 한다.

Root Aggregate의 역할은 Aggregate의 일관성을 깨지지 않게 하는 것으로, Aggregate 외부에서 Aggregate에 속한 내부 객체에 직접 변경하면 안되고, Root Aggregate를 통해서 접근해야 한다.

 

✔ Aggregate 이점

◼ 도메인 모델의 복잡성을 감소시킨다. -> 연관된 객체들을 묶어서 하나의 개념으로 다룰 수 있기 때문

◼ 도메인 객체의 일관성을 보장한다. -> 루트 엔티티를 통해 하위 엔티티들이 관리되기 때문

◼ 도메인 객체의 경계를 명확하게 정의할 수 있다. -> Aggregate 외부에서 내부 객체를 직접 접근하지 않도록 제한할 수 있다.

 

📒 정리

❗ 스프링 애플리케이션 패키지 구조 설계하기

완전히 생명 주기를 같이하고, 함께 조회되고 업데이트 되어야 하는 관계, 루트 엔티티 없이는 존재할 수 없는 관계들은 하나의 Domain 패키지 내에서 연관 관계를 맺어 개발하고, Root Aggregate의 Repository를 이용해 Root Aggregate를 조회한 후, 이후 하위 도메인에 대해 CRUD 작업을 진행한다.(CASCADE 옵션 사용)

이런 관계가 아닌 부분은 다른 domain내 패키지로 만든 후, 연관 관계가 아닌 기본 키를 갖는 형태로 설계한다.