DDD(Domain-Driven Design)란? 핵심 개념과 계층형 아키텍처

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

도메인 모델을 기반으로 복잡한 소프트웨어 시스템을 설계하고 개발하는 방법론

도메인(Domain)

• 소프트웨어가 해결하고자 하는 문제 영역
• → 도메인이 무엇인지 보다는 도메인에 포함되는 것이 무엇인가 정의를 내리는게 더 중요!

예를 들어 여행 애플리케이션은 예약, 결제, 여행 일정, 회원 관리 등의 하위 도메인으로 나눌 수 있다. 예약 도메인 안에는 예약 요청, 확정, 취소와 같은 상태와 행위가 존재할 수 있다.

이처럼 여러 도메인들이 상호작용하며, 비즈니스 도메인별로 나누어 설계하는 것을 도메인 주도 설계라고 한다.

도메인과 객체의 차이점

객체(Object)
객체는 프로그램에서 특정 개념을 표현하기 위해 상태와 행동을 하나로 묶은 단위이다.

객체는 현실 세계의 대상을 그대로 복사한 것이 아니라, 소프트웨어가 해결하려는 문제에 필요한 특징만 선택하여 추상화한 결과이다.
예를 들어 여행 서비스의 사용자 객체는 실제 사람의 모든 정보를 표현하지 않는다. 여행 서비스에서 필요한 사용자 식별자, 닉네임, 여행 성향 등의 정보만 포함할 수 있다.

도메인(Domain)

소프트웨어가 해결하고자 하는 문제 영역을 의미

예를 들어 여행 애플리케이션에는 회원 관리, 여행 일정, 예약, 결제, 리뷰 등의 도메인이 존재할 수 있다.
도메인 모델은 이러한 문제 영역의 개념과 규칙을 객체로 표현한 모델이다. 따라서 객체는 도메인을 코드로 표현하기 위한 수단이고, 도메인은 객체가 표현하려는 문제 영역이라고 볼 수 있다.

정리하면 다음과 같다.
• 도메인: 소프트웨어가 해결하려는 문제 영역
• 도메인 모델: 문제 영역의 개념과 규칙을 추상화한 모델
• 객체: 도메인 모델을 코드로 표현하는 수단

DDD의 핵심 목표는 복잡한 비즈니스 규칙을 도메인 모델에 명확하게 표현하고, 바운디드 컨텍스트를 통해 모델의 경계를 구분하는 것이다. 이를 통해 각 영역의 응집도를 높이고 영역 간 결합도를 낮춰 변경과 확장에 유연한 소프트웨어를 설계할 수 있다.

---

DDD 핵심 개념

유비쿼터스 언어 (Ubiquitous Language)

정의: 도메인 전문가와 개발자가 동일한 용어와 개념을 사용하도록 합의하고, 이를 모델과 코드에 반영한다.

이점: 의사소통 오류를 감소시키고 모델에 반영된 용어가 코드에도 그래도 쓰여, 일관성을 유지한다. 또한 도메인에 대한 이해를 높이기도 한다.

바운디드 컨텍스트(Bounded Context)

정의: 도메인이 여러 하위 영역으로 나뉘어 있을 때, 각 영역을 경계(Context)로 구분하고 독립된 모델을 유지하는 개념

• 서로 다른 바운디드 컨텍스트 간의 상호작용은 명확한 인터페이스를 통해 이루어진다.

이점: 영역별 요구사항 충돌 최소한다. 컨텍스트 간 의존관계를 명확히 정의해, 복잡도를 관리한다.

도메인 모델

정의: 도메인 지식을 코드 형태로 체계화한 추상화 모델

• 엔티티(Entity), 값 객체(Value Object), 서비스(Service), 리포지터리(Repository) 등의 구성요소로 이루어짐

역할: 비즈니스 로직을 객체지향적으로 표현해, 문제 해결 로직을 직관적으로 이해하게 한다. 또 한 유지보수성과 확장성을 향상시킨다.

애그리거트 (Aggregate)

정의: 도메인 모델의 일관성을 유지하기 위해 엔터티와 값 객체를 그룹화한 객체 군으로, 내부 일관성을 책임지는 단위

루트 엔티티(Root Entity): 애그리거트의 대표자 역할을 한다. 외부에서 애그리거트에 접근할 때, 루트 엔터티를 통해서만 조작한다.

엔티티 (Entity) 와 값 객체 (Value Object)

엔티티: 고유한 식별자(ID)를 갖고, 라이프사이클 전반에 걸쳐 상태가 변할 수 있는 객체

값 객체: 식별자 없이 불변성을 띠며, 동일한 속성이면 같은 객체로 취급

도메인 서비스 (Domain Service)

정의: 모델 객체(Entity, Value Object)로 표현하기 어려운 도메인 규칙이나 로직을 담당

역할: 여러 애그리거트를 한꺼번에 조작하거나, 계산 로직 등 비즈니스 로직 을 캡슐화해 코드의 응집도를 높인다.

레포지터리(Repository)

정의: 엔터티나 애그리거트를 저장하고 검색하는 추상화 계층

역할: 영속성(persistence) 로직을 캡슐화하여, 도메인 로직과 데이터 접근 로직을 분리한다.

---

DDD의 계층구조(Layerd Architecture)

계층이 나뉘어져 있는 아키텍처

주된 목표는 각각의 layer는 하나의 관심사에만 집중할 수 있도록 한다.

일반적으로 3 계층 또는 4계층으로 나누어 사용

※ 3계층으로 나눌 때는 표현 계층(Presentation Layer) → 서비스 계층 (Business Layer) → 영속성 계층(Persistence Layer)으로 나누어 사용하곤 한다.

규칙

1. 위의 계층에서 아래 계층에는 접근이 가능하지만 아래에서 위로는 불가능한 것을 기본으로 한다.
2. 한 계층의 관심사와 관련된 어떤 것도 다른 계층에 배치되어서는 안된다.

---

계층별 설명

1. Presentation Layer (표현 계층) (Controller)

사용자 요청에 대해 해석하고 응답하는 일을 책임지는 계층

• 사용자에게 UI를 제공하거나 클라이언트에 응답을 다시 보내는 역할을 하는 모든 클래스가 포함
• Client로부터 request를 받고 response를 return 하는 API 정의

2. Application Layer (응용 계층) (Service)

비즈니스 로직을 정의하고 정삭적으로 수행될 수 있도록 도메인 계층과 인프라스트럭쳐 계층을 연결해주는 역할을 하는 계층

• 이 계층은 많은 정보를 가지고 있지 않게 유지하는 것이 중요하다
• 실직적인 데이터의 상태 변화 등의 처리는 도메인 계층에서 진행할 수 있도록 위임하는 것이 중요

기능

1. 트랜잭션의 단위
2. DTO 변환
3. 엔터티 조회/저장
   • 단순하게 말하면 Entity를 찾고 (Repository), 변경 내용을 저장하는 기능(Persistence)을 호출한다.
   구현은 Infra Layer에서 한다
4. 사용자 인증/인가
   • 사용자가 특정 URL에 대해 권한이 있는지 정도의 인가는 presentation layer에서 하지만, URL만으로 판단이 어렵거나, DB내의 데이터와 대조해봐야 알 수 있는 경우 (데이터 존재 여부, 중복 여부 등)
5. 파라미터 검증
   • presentation layer에서도 수행할 수 있지만 주로 요청 방식에 따라 달라지는 ‘형식’에 대한 검증을 하고, application layer에서는 ‘논리적’인 오류를 검증한다.

3. Domain Layer (도메인 계층) (Model)

비즈니스 규칙, 정보에 대한 실질적인 도메인에 대한 정보를 가지고 있으며 이 모든 것을 책임지는 계층

• Entity를 활용하여 도메인 로직이 실행되며, 업무 상황을 반영하여 상태를 제어하는 역할에 집중하는 계층

4. Infrastructure Layer (인프라 계층)

외부와의 통신(DB, 메시징 시스템 등)을 담당하는 계층

• 해당 계층에서 얻어온 정보를 응용 계층 또는 도메인 계층에 전달하는 것이 주 역할

각각의 도메인들을 위와 같은 Layer로 철저히 분리해서 만드는 것이 DDD(Domain-Driven Design)의 핵심 설계

Layered Architecture의 장단점

Layered Architecture 장점

• 각 레이어를 Loosely Coupling된 형태로 구축하면서, 각각 자신의 관심사에만 집중할 수 있다.
• 핵심 비즈니스 로직을 순수하게 유지함으로써 유지보수와 확장성 측면에서 이득을 얻을 수 있다.
• 각 레이어에 서로 다른 추상화 수준을 가진 상태와 행동을 위치시킴으로써 코드 재사용성을 높일 수 있다.

Layered Architecture 단점

• 서비스가 커질수록 복잡도가 증가하여 확장성이 떨어진다.
• 레이어로 분리된 관심사 외에 다른 관심사가 생길 경우 패키지 분리 및 코드 배치가 어렵다.

---

출처

https://limdae94.tistory.com/84

https://tech.kakaopay.com/post/backend-domain-driven-design/

https://wikidocs.net/275501

https://dev-coco.tistory.com/166