DDD란?

• "Domain-Driven Design"의 약자로, 소프트웨어 개발에서 도메인(문제 영역)에 집중하여 설계하는 방법론입니다.
  DDD는 복잡한 비즈니스 요구사항을 효과적으로 모델링하고, 소프트웨어 아키텍처를 개선하는 데 도움을 줍니다. 이를 통해 개발자와 비즈니스 간의 협업을 강화하고, 유지보수성을 높일 수 있습니다.

1. DDD 구조

(1) 도메인 모델

• 도메인 모델은 도메인 주도 설계(DDD)에서 핵심 “개념”을 표현하는 방법입니다.
• 도메인 모델은 크게 엔티티(Entity)와 벨류(Value) 로 나뉘어 질 수 있습니다.
  엔티티(Entity)는 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖습니다. 주문(Order), 회원(Member), 상품(Product)과 같이 도메인의 고유한 개념을 표현합니다.
• 벨류(Value)는 고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현할 때 사용됩니다.
  배송지 주소를 표현하기 위한 주소(Address)나 구매 금액을 위한 금액(Money)와 같은 타입이 Value 타입입니다.

(2) 도메인 서비스

• 특정 엔티티에 속하지 않는 도메인 로직을 담당
  예를 들어, "할인 금액 계산"은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 고려하여 이루어지는데,
  이 로직의 주체가 명확하지 않을 때가 있습니다. 이처럼 여러 엔티티와 값이 필요한 도메인 로직은 도메인 서비스에서 구현할 수 있습니다.

(3) DDD 계층

• Layered Architecture 와 같이 표현,응용,도메인,인프라스트럭처 4개의 계층으로 이루어져 있으며
  고수준 모듈이 저수준 모듈에 의존하지 않는 구조로 개발이 필요합니다. 만약 불가피하게 응용 계층에서 인프라스트럭처의 코드를 사용 할 경우 의존역전원칙(DIP) 을 이용하여 하위 계층에 의존하지 않는 형태로 개발해야 합니다.
• domain, application, infrastructure, presentation 순으로 고수준 모듈이라고 정의합니다

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

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

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

• 비즈니스 로직을 정의하고 정상적으로 수행될 수 있도록 Domain 계층과 Infrastructure 계층을 연결
• 해당 계층은 많은 정보를 가지고 있지 않게 유지하는 것이 중요
• 실질적인 데이터의 상태 변화 등의 처리는 도메인 계층에서 진행할 수 있도록 위임하는 것이 중요
• 트랜잭션의 단위, DTO 변환, 엔티티 조회/저장이 해당 Layer에 포함됨
• 현재 로그인한 사용자가 특정 URL에 대해 권한에 따른 인가는 Presentation Layer에서 하지만, DB내의 데이터와 대조해봐야 알 수 있는 경우 해당 계층에서 진행
  
  

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

• 비즈니스 규칙, 정보에 대한 실질적인 도메인에 대한 정보를 가지고 있으며 이 모든 것을 책임지는 계층
• Entity를 활용하여 도메인 로직이 실행되며, 업무 상황을 반영하여 상태를 제어하는 역할에 집중하는 계층
  
  

(4) Infrasturcture Layer(인프라 계층) (Repository)

• 외부와의 통신(DB, 메시징 시스템 등)을 담당하는 계층
• 해당 계층에서 얻어온 정보를 응용 계층 또는 도메인 계층에 전달하는 것이 주 역할이다.

2. JPA에서의 DDD

• 도메인 모델을 관리할 때 비즈니스 로직과 도메인 모델간의 결합도를 낮추기 위해 리포지토리 패턴을 권장하고 있습니다.
• 리포지토리 패턴은 특정 도메인 모델을 관리하는 메서드를 리포지토리라는 이름의 클래스로 구성하여 "이 도메인 모델의 변경은 이 리포지토리만을 통해서만 가능하다"라고 제한하여 유연한 구조를 가져갈 수 있는 설계 패턴 입니다. 이는 Spring JPA에서의 JpaRepository와 매우 유사하기 때문에 JPA를 사용할 경우 별다른 구성 없이 리포지토리 패턴을 사용할 수 있습니다.
• DDD에서는 도메인 모델이 애플리케이션의 핵심입니다. 그리고 JPA는 @Entity 어노테이션을 통해 객체 지향적인 방식으로 데이터베이스와 상호작용할 수 있게 해주며, 도메인 객체를 Jpa 엔티티에 그대로 사용할 수 있게 합니다.

애그리거트에는 반드시 하나의 루트 애그리거트가 존재하고 루트 애그리거트는 하위 애그리거트들을 관리하는데 그럼 루트 애그리거트와 하위 애그리거트를 어떻게 구현할 수 있을까??


=> JPARepository를 루트 애그리거트에만 구현하는 것으로 가능합니다.
이렇게 하면 루트 애그리거트가 하위 애그리거트들을 관리하고 영속성 관련 로직도 루트 애그리거트에 집중할 수 있습니다.


예를 들어, 현재 Order <-> OrderProduct <-> Product의 구조로 OrderProduct와 Order, Product간의 1:N관계로 연관 매핑이 되어 있고 제품의 가격 정보를 수정하고 싶을때
Order(루트 애그리거트) -> OrderProduct(하위 애그리거트) -> Receipt(하위 애그리거트)를 호출하여 값을 수정할 수 있다.

3. MSA에서의 DDD

• 복잡한 비즈니스 로직이나 모놀리식 애플리케이션을 MSA로 전환할 때, 가장 중요한 것은 서비스의 경계를 명확히 나누는 것입니다. 예를 들어, 모놀리식 이커머스 플랫폼을 MSA로 전환할 때는 주문, 상품, 리뷰와 같은 도메인 개념을 기준으로 마이크로서비스를 구축하게 됩니다.

• DDD는 도메인 모델을 중심으로 비즈니스 로직을 정의하고, 이를 독립적인 도메인 경계로 나눕니다. 따라서 MSA와 DDD를 함께 사용하면, 도메인 경계를 기반으로 각 도메인에 해당하는 마이크로서비스를 정의할 수 있습니다. 이렇게 하면 각 마이크로서비스는 단일 책임 원칙을 따르고, 특정 비즈니스 기능에 집중할 수 있게 됩니다.

참고자료
https://dev-coco.tistory.com/166