DDD(Domain-Driven Design)

DDD란?

 

소프트웨어의 복잡성을 줄이고, 도메인 로직을 중심으로 개발을 진행하기 위해 계층화된 파일 구조다. 대표적으로

 

domain - 애플리케이션의 핵심 비즈니스 로직

application(애플리케이션 계층) - 유스케이스 구현, 도메인 계층 호출

infrastructure(기술적 계층) - db, 메시징 시스템, 외부api, 파일 시스템 등 외부 기술과의 통합을 담당

interfaces - 사용자와 상호작용하는 인터페이스. rest api, 웹 페이지, cli

 

로 이루어져있다.

 

DDD는 SRP를 완벽히 따르며, 도메인 모델을 가장 중요하게 여긴다.

도메인 로직은 domain 계층에 집중해야 하며, 다른 계층에 의존하지 않는다.

계층 간의 의존성 흐름은 interfaces -> application -> domain 순이다.

 

 

Aggregate Root

 

특정 Aggregate(집합) 의 진입점 역할을 한다. Aggregate는 여러개의 엔티티와 밸류 오브젝트로 구성되며, 외부에서 접근할 때 반드시 Root를 통해야 한다. aggregate root는 aggregate의 라이프사이클을 완전히 관리하여 내부의 데이터를 보호하고 일관성을 유지시켜준다.

 

예를 들어, board가 aggregate root라면 외부는 comment에 직접 접근하지 않고 반드시 board를 통해 접근해야 한다.

 

aggregate root간의 관계는 명확히 정의되어야 한다. 같은 aggregate에 속하는지, 별개의 aggregate로 나뉘는지 명확히 결정해야 한다.

 

 

도메인이란?

 

소프트웨어 개발에서 해결하려는 문제나, 모델링하려는 특정 비즈니스 영역을 의미한다.

 

ex.전자상거래 시스템 도메인

코어 도메인: 주문처리, 결제 로직(주문 Aggregate Root와 결제 Aggregate Root)

서브 도메인: 배송 관리(support), 사용자 인증 및 권한 관리(generic)

전자상거래 도메인
├── 주문 (Order)
│   ├── 엔티티: 주문(Order), 주문 항목(OrderItem)
│   ├── 밸류 오브젝트: 가격(Price), 주소(Address)
│   └── 로직: 주문 생성, 주문 상태 변경
├── 결제 (Payment)
│   ├── 엔티티: 결제(Payment)
│   ├── 로직: 결제 승인, 환불 처리
└── 배송 (Delivery)
    ├── 엔티티: 배송(Delivery)
    ├── 로직: 배송 시작, 배송 완료

 

DDD에서 도메인의 역할은,

유비쿼터스 언어: 개발자와 도메인 전문가(사업부) 가 공통적으로 사용하는 용어를 정의해 소통한다.

도메인 계층: 애플리케이션 계층과 기술적 계층과 독립적으로 비즈니스 규칙과 로직을 캡슐화해서 관리한다.

 

 

캠프 과제에서 진행한 user 도메인을 가져와서 원래 진행중인 프로젝트에 적용시키고, DDD 원칙을 준수해 파일을 전체적으로 리팩토링했다.

도메인 계층: board aggregate root와 user aggregate root로 이루어져있다.

애플리케이션 계층: dto, mapper, exception 등 domain에 의존하는 친구들이다.

인터페이스 계층: 애플리케이션 계층에 의존한다. 사용자와 상호작용하는 restapi를 담고있다.

기술 계층: 기술적인 요소들을 담고있다. configuration이나, db와 상호작용을 하거나, redis를 관리한다.