DDD

Domain Driven Design

DDD(Domain-Driven Design)는 소프트웨어 개발 방법론 중 하나로, 복잡한 도메인을 다루는 소프트웨어 시스템을 개발하기 위한 접근 방식입니다. DDD는 도메인의 복잡성에 초점을 맞추고, 도메인 전문가와 개발자 간의 협업을 강조합니다.

주요 개념과 원칙

도메인

• 소프트웨어 시스템이 적용되는 문제 영역 또는 업무 영역을 말합니다. 도메인은 복잡한 비즈니스 규칙, 개념, 프로세스 등을 포함하며, 소프트웨어 시스템은 도메인을 모델로 표현합니다.

도메인 모델

• 도메인을 표현하기 위한 추상화된 개념이자 구조입니다. 도메인 모델은 도메인의 핵심 규칙, 개념, 프로세스를 객체, 값 객체, 엔티티, 애그리게잇 등의 개념을 사용하여 표현합니다.

애그리게잇(Aggregate):

• 관련된 객체들의 그룹을 하나의 단위로 묶은 개념입니다. 애그리게잇은 내부적으로 일관된 상태를 유지하고 도메인 규칙을 적용합니다. 애그리게잇은 도메인 모델의 중심 요소이며, 도메인의 경계와 일관성을 유지하는 역할을 합니다.

도메인 주도 설계:

• 도메인을 중심으로 시스템을 설계하는 방법론입니다. 도메인 주도 설계는 도메인 전문가와 개발자 간의 협업을 강조하고, 도메인 모델링을 통해 문제 영역을 이해하고 설계하는 방식을 추구합니다.

아키텍처 구성

사용자 인터페이스 UI 또는 표현 Presentation

• 사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있다.

응용 Application

• 사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 싱행한다

도메인

• 시스템이 제공할 도메인 규칙을 구현한다.

인프라스트럭처 infrastructure

• 데이트베이스나 메시징 시스템과 같은 외부 시스템관의 연동을 처리한다

엔티티와 밸류

엔티티

• 엔티티는 식별 가능하고 변경 가능한 개념을 나타냅니다. 엔티티는 주로 고유 식별자를 가지며, 그 식별자를 기반으로 도메인에서 식별됩니다.

  • 예를 들어, 고객(Customer) 엔티티는 고객의 고유한 식별자로 식별될 수 있습니다.

• 엔티티는 고유한 식별자에 의해 식별됩니다. 엔티티의 속성이 변경되더라도 식별자가 유지되면 여전히 같은 엔티티로 취급됩니다.

  • 예를 들어, 고객의 이름이 변경되더라도 식별자로 고객을 식별할 수 있습니다.

• 엔티티는 변경 가능한 상태를 가질 수 있습니다. 도메인 규칙에 따라 엔티티의 속성이 변경되고, 엔티티의 상태를 변경할 수 있습니다.

• 엔티티는 도메인에서 개체(Entity)로서 중요한 역할을 수행합니다. 엔티티는 도메인의 핵심 개념을 표현하고 도메인 규칙을 적용하는데 사용됩니다.

밸류

• 밸류는 변경 불가능하고 동등성(Equality)을 기준으로 비교됩니다. 밸류는 주로 도메인에서 개념적인 속성을 나타냅니다.

  • 예를 들어, 주소(Address) 값 객체는 일련의 속성(도시, 우편번호 등)을 가지고 있으며, 두 주소가 동일한 속성을 가지면 동등하다고 판단됩니다.

private String city; // 도시
private String zipCode; // 우편번호

// ===>

public class Address {
    private String city;
    private String zipCode;
}

• 밸류는 그 자체로 식별되지 않고, 속성의 조합으로 식별됩니다. 밸류는 속성이 변경되면 새로운 값 객체로 취급됩니다.

  • 예를 들어, 주소의 속성이 변경되면 새로운 주소 객체가 생성됩니다.

• 밸류는 변경 불가능한(Immutable) 속성을 가집니다. 밸류의 속성은 생성 시점에 결정되고 이후에는 변경되지 않습니다. 밸류의 속성을 변경하려면 새로운 값 객체를 생성해야 합니다.

• 밸류는 도메인에서 개념적인 속성을 나타내는데 사용됩니다. 밸류는 도메인의 특정 속성을 표현하고, 값의 변경이나 동등성 비교에 사용됩니다.

도메인 영역의 주요 구성요소

엔티티(ENTITY)

• 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문(Order), 회원(Member), 상품(Product)과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.

밸류(VALUE)

• 고유의 식별자를 갖지 않은 객체로 주로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소(Address)나 구매 금액을 위한 금액(Meney)와 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다.

애그리거트(AGGREGATE)

• 애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 '주문' 애그리거트로 묶을 수 있다.

리포지터리(REPOSITORY)

• 도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.

도미엔 서비스(DOMAN SERVICE)

• 특정 엔티티에 속하지 않은 도메인 로직을 제공한다. '할인 금액 계산'은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

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

바운디드 컨텍스트(Bounded Context)는 도메인 주도 설계(Domain-Driven Design)에서 중요한 개념 중 하나입니다. 바운디드 컨텍스트는 소프트웨어 시스템을 작은 도메인 모델로 분할하는 기술적 그룹화를 나타냅니다. 각 바운디드 컨텍스트는 특정 비즈니스 도메인과 관련된 기능, 규칙, 프로세스 등을 포함하고, 해당 도메인에 대한 명확한 경계를 정의합니다.

특징

경계:

• 각 바운디드 컨텍스트는 특정 도메인을 나타내며, 해당 도메인의 경계를 정의합니다. 서로 다른 바운디드 컨텍스트는 독립적으로 개발, 배포 및 관리될 수 있습니다.

모델:

• 바운디드 컨텍스트는 특정 도메인에 대한 모델을 포함합니다. 이 모델은 도메인의 핵심 개념, 엔티티, 값 객체, 애그리게이트 등을 포함하며, 해당 도메인에 필요한 비즈니스 규칙과 로직을 반영합니다.

유비쿼터스 언어:

• 바운디드 컨텍스트는 특정 도메인을 이해하기 위한 공통 언어인 유비쿼터스 언어를 사용합니다. 유비쿼터스 언어는 도메인 전문가, 개발자, 사용자 등 모든 이해관계자들이 사용할 수 있는 공유 언어입니다.

컨텍스트 매핑:

• 서로 다른 바운디드 컨텍스트 간에는 컨텍스트 매핑을 통해 상호작용할 수 있습니다. 컨텍스트 매핑은 각 컨텍스트의 경계를 넘어서 도메인 이벤트, 요청, 응답 등을 교환하고 데이터 일관성을 유지하는 방법을 제공합니다.

Architecture

Layered

• Presentation Laye

  • Presentation Layer는 사용자와 상호작용하고 정보를 표시하는 레이어입니다. 사용자 인터페이스(UI)와 관련된 기능을 담당합니다. 웹 애플리케이션의 경우 HTML, CSS, JavaScript를 사용하며, 모바일 앱이나 데스크톱 애플리케이션에서는 해당 플랫폼의 UI 컴포넌트를 사용합니다.

• Application Layer

  • Application Layer는 비즈니스 로직을 처리하는 레이어입니다. 응용 프로그램의 핵심 기능을 구현하고, 사용자 요청을 처리하여 도메인 레이어로 전달합니다. 이 레이어는 도메인의 핵심 개념을 이해하고 비즈니스 규칙을 적용합니다.

• Domain

  • Domain Layer는 Layered Architecture에서 중요한 부분입니다. 도메인 레이어는 소프트웨어 시스템의 핵심을 대표합니다. 도메인 모델, 엔티티, 값 객체, 애그리게이트 등의 개념을 포함하며, 도메인 규칙과 도메인 특화 로직을 구현합니다.

• Infrastructure

  • Data Access Layer는 데이터베이스나 외부 시스템과의 상호작용을 처리하는 레이어입니다. 데이터 액세스, 데이터 조작, 데이터베이스와의 연결 등을 담당합니다. 이 레이어는 데이터 저장소와의 인터페이스를 구현하고, 응용 프로그램의 데이터 요구를 처리합니다.

Clean

• 엔티티(Entity):

  • 엔티티는 애플리케이션의 핵심 비즈니스 규칙을 포함하는 가장 안쪽 레이어입니다. 도메인 모델을 구성하고 비즈니스 도메인 로직을 포함합니다. 엔티티는 시스템의 다른 레이어와 독립적으로 존재할 수 있어야 합니다.

• 유스케이스(Use Case):

  • 유스케이스 레이어는 엔티티에 의존하며, 비즈니스 로직을 구현합니다. 사용자의 요청을 처리하고 엔티티에 대한 조작을 제어합니다. 유스케이스 레이어는 애플리케이션의 특정 기능 또는 사용 사례에 해당하는 코드를 포함합니다.

• 인터페이스(Interface):

  • 인터페이스 레이어는 사용자와 시스템 간의 상호작용을 처리합니다. 이는 사용자 인터페이스(UI), 웹 API, CLI(Command Line Interface) 등을 포함할 수 있습니다. 인터페이스 레이어는 사용자의 입력을 받아 유스케이스 레이어로 전달하고, 그 결과를 사용자에게 반환합니다.

• 프레임워크 및 드라이버(Frameworks and Drivers):

  • 프레임워크 및 드라이버 레이어는 외부 요소와의 연동을 담당합니다. 데이터베이스, 웹 프레임워크, 서드파티 라이브러리 등과의 상호작용을 처리합니다. 이 레이어는 내부의 안쪽 레이어에 대한 의존성을 가지며, 외부 요소에 대한 세부 구현을 캡슐화합니다.

Hexagonal

• 사용자 인터페이스(User Interface):

  • 사용자와 시스템 간의 상호작용을 처리합니다. 사용자의 입력을 받고, 출력을 표시하는 등의 역할을 담당합니다.

• 어플리케이션(Application):

  • 비즈니스 로직을 포함하고 있으며, 사용자 인터페이스로부터의 요청을 처리합니다. 이는 시스템의 핵심 기능을 구현하는 부분입니다.

• 포트(Ports):

  • 외부 요소와의 상호작용을 추상화합니다. 주로 인터페이스로써 역할을 하며, 외부 시스템이나 데이터베이스 등과의 통신을 처리합니다.

• 어댑터(Adapters):

  • 포트와 실제 구현체 간의 연결을 담당합니다. 어댑터는 포트를 구현하고, 해당 포트를 통해 외부 시스템과 상호작용합니다.

• 도메인(Domain):

  • 비즈니스 도메인의 핵심 규칙과 개념을 포함합니다. 도메인은 시스템의 핵심 로직을 담당하며, 비즈니스의 본질적인 특성을 표현합니다.

• 인프라스트럭처(Infrastructure):

  • 데이터베이스, 외부 서비스, 외부 시스템과의 통신 등과 같이 시스템의 인프라를 구성하는 요소들을 포함합니다.

Reference

책: 도메인 주도 개발 시작하기 - 최범균

ㄷㄷㄷ: Domain Driven Design과 적용 사례공유 / if(kakao)2022