[IT정보] 도메인 주도 설계(Domain Driven Design, DDD) 개념

도메인 주도 설계(Domain Driven Design, DDD)란? 도메인 주도 설계(Domain Driven Design, DDD)는 비지니스 도메인(Business Domain)과 일치하도록 소프트웨어를 모델링하는 데 중점을 둔 소프트웨어 설계 접근 방식을 말합니다. 비지니스 도메인(Business Domain)이란? 비지니스 도메인은 유사한 업무의 집합을 의미합니다.

쉽게 말하면, 소프트웨어 코드의 구조와 언어(클래스 이름, 클래스 메소드, 클래스 변수)를 비즈니스 도메인의 용어에 일치시켜 나간다는 것입니다. 예를 들어 소프트웨어가 대출 응용 프로그램을 처리하는 경우 LoanApplication과 Customer와 같은 클래스와 AcceptOffer와 Withdraw 같은 메서드 이름을 명명할 수 있습니다. 참고 DDD는 기존의 애플리케이션 설계가 비즈니스 도메인에 대한 이해가 부족한 상태에서 설계 및 개발되었다는 것에 대한 반성의 의미로 시작되었습니다. DDD에서는 기존의 현업에서 IT로의 일방향 소통구조를 탈피하여 현업과 IT의 쌍방향 커뮤니케이션을 매우 중요하게 생각합니다. DDD 목표 DDD의 핵심 목표는 애플리케이션 또는 그 안의 모듈간의 의존성은 최소화(Loosly coupling)하고, 응집성은 최대화(High cohesion)하는 것입니다. ​

그리고 DDD는 다음과 같은 목표를 기반으로 합니다. ​

▶ 핵심 도메인과 그 기능에 집중하라.
▶ 도메인의 모델의 정교하게 구축하라.
▶ 애플리케이션 모델을 발전시키고 새롭게 생기는 도메인 관련 이슈를 해결하기 위해 도메인 전문가와 끊임없이 협력하라.

DDD 방식 DDD는 다음과 같이 개념 설계(Strategic Design)와 개발을 위한 구체적인 설계(Tactical Design)로 나눌 수 있습니다. 1. 개념 설계(Strategic Design) 컨텍스트(Context)에 대해 생각하고 이를 기준으로 설계하는 것을 의미합니다.(여기서 Context 란 특정 객체 혹은 상황이 벌어지는 주변 환경을 의미함) ​ Strategic Design을 이해하기 위한 예시로 주택을 만드는 경우를 생각해 봅시다. 주택을 만들기 위한 행동 절차는 다음과 같을 것입니다. ​
1. 어떤 주택을 지을지 생각합니다.
2. 그리고 주택 전문가와 상의합니다.
3. 주택을 지을 때 어떤 핵심적인 가치에 집중하여 집을 지을지를 선택합니다. 예를 들어 안방이 넓어야 한다던가, 화장실은 2개가 필요 한다던가 중점적인 사항을 명시합니다.
4. 다른 집들을 최대한 많이 조사하여 마음에 원하는 집의 형상을 떠올려 봅니다.
5. 그리고 그 형상을 실제 집으로 만들어 내기 위해 모델링을 합니다.
6. 이를 토대로 구체적인 설계도를 그립니다. 이 설계도에는 주택의 매우 구체적인 부분들이 명시됩니다. ​ 이렇게 DDD를 통한 설계 과정에서 사용되는 용어는 다음과 같습니다. 용어 설명 Domain 주택 전체 설계 Subdomain 주택을 구성하는 부분 집합 안방, 화장실, 창고 등 Domain Model 실제 Subdomain의 구체적인 형상 Context 주택을 구성하는 각 부분들에 대한 환경 Bounded Context 주택을 구성하는 요소들 각각을 둘러싼 상황을 의미합니다. ​

특정 모델은 어떤 bounded context에 놓이는가에 따라 다르게 이해될 수 있습니다. 예를 들어, 주택 정문에서 caretaker라는 모델이 있다면 이는 '경비원'을 뜻합니다. 하지만 이 단어가 주택 건물 안에서 가지는 의미는 '아이를 돌보는 사람'이 될 수 있습니다. Ubiquitous Language Bounded Context를 구성하는 화장실, 안방, 창고 등과 같은 주택 설계자와 건축업자 등 모든 사람들이 공통으로 이해하고 사용하는 어휘 Context Map 각 Bounded Context들 사이의 관계성 2. 구체적 설계(Tactical Design)
▶ Tactical Design은 개발을 위해 구체적으로 설계하는 것을 의미합니다. ​
▶ Tactical Design은 Strategic Design과 달리 개발을 진행하는 과정에서 계속해서 바뀌고 개선됩니다. ​
▶ Tactical Design을 이해하기 위한 Model Driven Design은 Strategic Design 방식으로 설계한 각 Subdomain별 Domain Model(Context Map)을 중심으로 설계하는 방식을 말합니다. Model Driven Design And Service
▶ 계층화된 아키텍처(Layered Architecture)는 Tatical Design 시 모든 프로세스를 업무순서로 쪼게고 계층을 나누어 설계하는 것을 의미합니다. ​ 스프링 부트(Spring Boot)에서는 각 계층(Layer)의 목적에 맞게 3가지 어노테이션(Annotation)을 지원합니다. Layer Annotation Presentation Layer @Controller, @RestController Service Layer, Domain Layer @Service Data Layer @Repository

▶ Entity
- Entity는 각 레코드 간에 구별이 필요한 객체입니다.
- Entity는 가변적(Mutable)입니다.
- 예를 들어 '지폐'라는 객체는 '일련번호'라는 고유ID로 구별되어야 하므로 Entity 입니다. ​

▶ Value Object(VO)
- VO는 각 레코드 간에 구별이 필요없는 객체입니다.
- VO는 불변성(Immutable)을 가집니다.
- 예를 들어 '금액'이라는 객체는 '액수'와 '통화'라는 속성이 중요하지 구별할 필요가 없으므로 VO입니다. ​

▶ Aggregate
- Aggregates는 Entity의 집합입니다.
- 예를 들어 cutomer, customerInfo, address 라는 세가지 종류의 Entity를 생각해 보면, 사실 이 모든 정보는 Customer라는 주제로 뭉칠 수 있습니다. ​

▶ Factories Factories는 복잡한 Entity 혹은 Aggregate를 생성하는 것을 담당합니다. ​

▶ Repositories - Data access를 처리하는 객체입니다.
- Aggregate, Entity를 위해 데이터 CRUD를 담당합니다.
- 실제 구현시에는 JPA나 Mybatis와 같은 ORM을 사용하는 것이 가장 이상적입니다. 레퍼런스(Reference)