도메인 모델 패턴 및 DDD

임태환·2025년 2월 13일

msa 스터디

study

목록 보기

5/10

도메인 모델 패턴이란?

현실 세계의 개념과 규칙을 객체(Entity)로 표현하여 데이터를 저장하고
비즈니스 로직을 객체 내부에 포함시키는 설계 방식이다.

도메인 모델 패턴을 사용하는 이유?

객체 내부에 데이터 저장 및 비즈니스 로직을 포함한다 했는데
이러한 경우 장점들이 존재한다.

장점	설명
응집도 상승	데이터와 로직이 한 곳에 있어 해당 도메인에 대한 관리가 수월합니다.
변경에 강함	데이터 구조나 비즈니스 규칙이 변경되어도 해당 객체만 수정하면 됩니다.
재사용성 용이	도메인 객체를 다른 컨텍스트(context)에서도 쉽게 재사용할 수 있습니다.
테스트성 용이	각 클래스를 독립적으로 테스트할 수 있어 테스트가 용이합니다.
확장성 용이	전략 패턴 및 템플릿 메서드 패턴을 적용하여 컴포넌트를 쉽게 확장할 수 있습니다.
중복 코드 제거	서비스 계층이나 다른 계층에서 중복된 코드를 작성하지 않아도 됩니다.

도메인 모델 패턴의 특징

객체가 데이터를 스스로 관리한다.

ex) 주문 객체가 직접 주문 생성이나 취소 같은 작업을 처리

관련된 데이터와 로직을 한 곳에서 관리

데이터와 비즈니스 로직을 분리하지 않고 한 곳에서 관리한다.

비즈니스 규칙을 객체 내부에서 처리

서비스 계층에서 처리하던 로직을 Entity가 스스로 처리한다.

도메인 모델 패턴의 구성 요소(빌딩 블록)

구성 요소	정의	역할
엔티티 (Entity)	고유 식별자를 가지며 상태와 행동을 포함하는 도메인 객체	데이터를 저장하고 비즈니스 로직을 실행
밸류 객체 (Value Object)	고유 식별자가 없으며 값 자체로 동일성을 판단	값을 표현하고 불변성을 유지
애그리거트 (Aggregate)	관련된 엔티티와 밸류 객체를 묶어 일관성을 유지하는 단위	외부에서는 루트를 통해 접근하며 내부 상태를 보호
팩토리 (Factory)	복잡한 객체(엔티티 또는 애그리거트)를 생성하는 책임	복잡한 초기화 과정을 캡슐화하고 비즈니스 규칙을 적용
리포지토리 (Repository)	애그리거트를 저장하고 조회	데이터 접근 로직 캡슐화
서비스 (Service)	도메인 객체에 포함되지 않는 비즈니스 로직 또는 워크플로우를 처리	여러 애그리거트를 조율하거나 사용자 요청과 응답을 처리

DDD(도메인 주도 설계)란?

DDD는 복잡한 비즈니스 로직을 개발하기 위해 OOD를 개선한 접근 방식으로
비즈니스 중심으로 설계를 진행하는 방법론이다.

DDD의 핵심 개념

도메인
- 도메인은 소프트웨어가 해결하려는 문제의 영역
  - 예시) 주문, 결제, 배송
하위 도메인
- 큰 도메인을 더 작은 단위로 세분화
  
  하위 도메인으로 왜 나누는지?
  1.복잡한 문제를 쪼개어 이해 및 관리성 용이를 위해
  2.하위 도메인마다 중요도를 구분하여 핵심 하위 도메인에 리소스 집중
  3.하위 도메인을 독립적으로 설계 및 개발하기 위해

핵심 하위 도메인
예시) 주문과 결제는 핵심 하위 도메인이 될 수 있다.
지원 하위 도메인
예시) 배송 관리는 핵심 기능인 배송을 지원하는 역할
일반 하위 도메인
예시) 이메일 발송이나 알림은 일반적인 기능이다.

3.유비쿼터스 언어

개발자와 비즈니스 전문가가 공통으로 사용하는 언어
- 코드와 대화에서 동일한 용어 사용으로 협업 원활

4.경계 컨택스트(Bounded Context)

하나의 하위 도메인을 독립적으로 관리하기 위한 경계
각 경계 컨텍스트는 자신의 객체,로직을 독립적으로 가짐

예시

주문 관리(Order Management)
주문 생성, 수정, 취소 등의 기능 포함.
Order와 관련된 모든 엔티티와 로직을 포함.

결제 처리(Payment Processing)
결제 승인, 결제 취소 등의 기능 포함.
결제와 관련된 엔티티(Payment, PaymentDetails)를 독립적으로 관리.

배송 관리(Delivery Management)
배송 상태 업데이트 등의 기능 포함.
배송과 관련된 엔티티(Delivery, TrackingInfo)를 독립적으로 관리.

5.Aggregate(애그리거트)

관련된 엔티티와 밸류 객체를 묶어서 하나의 단위로 관리
애그리거트 내부는 일관성을 유지해야하며 (일관성 경계)
애그리거트 내부의 모든 엔티티와 값 객체는 루트를 통해 접근(애그리거트 루트)

6.Repository(리포지토리)

리포지토리는 애그리거트를 저장하고 조회하는 역할
DB와 상호작용하지만, 도메인 계층에서는 추상화하여 사용

7.Service(서비스)

서비스는 도메인 객체에 포함되지 않는 비즈니스 로직 또는 워크 플로우 처리

1)도메인 서비스

특정 비즈니스 로직이 여러 애그리거트에 걸쳐 있을 경우 사용

2)애플리케이션 서비스

사용자 요청과 응답 처리, 도메인 계층과 API,UI를 연결

DDD의 장단점

구분	내용
장점
비즈니스 중심 설계	소프트웨어가 실제 비즈니스 문제를 정확히 해결하도록 설계됩니다.
유지보수성 향상	도메인이 명확히 정의되어 있어 코드가 직관적이고 유지보수가 쉽습니다.
확장성	새로운 요구사항이 생겨도 모델 확장이 용이합니다.
협업 강화	개발자와 비즈니스 전문가가 같은 언어(Ubiquitous Language)를 사용하므로 협업이 원활해집니다.
단점
초기 비용 증가	도메인을 깊이 이해하고 모델링하는 데 많은 시간이 필요합니다.
복잡성 증가	작은 프로젝트에서는 과도한 설계로 보일 수 있습니다.
전문성 요구	DDD를 제대로 적용하려면 높은 수준의 설계 능력과 경험이 필요합니다.