chap01. Domain Driven Design

  • DDD란?
    • 비즈니스 Domain 별로 나누어 설계하는 방식
      • 기존의 어플리케이션 설계가 비즈니스 도메인에 대한 이해 부족한 삭태에서 설계 및 개발되었다는 반성에서 출발
      • DDD 는 기존의 현업에서 IT 로의 일방향 소통구조를 탈피하여 현업과 IT의 쌍방향 커뮤니테이션을 중요하게 생각
    • DDD의 핵심 목표는 Loosly coupling, High cohesion
    • DDD는 Strategic Design, Tactical Design으로 나눌 수 있다
      • Strategic Design 는 개념 설계
      • Tactical Design 은 프로그래밍하기 위한 구체적 설계
  • 전략적 설계
    • 비즈니스 상 전략적으로 중요한 것, 중요도에 따라 일을 나누고 필요에 따라 최적의 방법 강조
    • 바운디드 컨텍스트라는 전략적 설계패터을 사용하여 도메인 모델을 분리하고 이와 밀접한 관련이 있는 바운디드 컨텍스트 안의 도메인 모델에서 보편언어 개발
    • 도메인 전문가가 참여하여 보편언어를 함께 개발
    • 보편언어는 의사소통, 모델 곳곳에 보편적이고 널리 퍼져있게 된다
  • 전술적 설계
    • 도메인 모델의 세부사항
    • 엔티티와 값 객체(Value Object) 를 알맞은 Aggregate 로 묶는 Aggregate Pattern
    • Domain Event 를 통해 시스템 공유 (동일한 바운디드 컨텍스트 일수도 있고 다른 원격의 바운디드 컨텍스트 일수도 있다)

chap02. Bounded context 및 보편언어와 전략적 설계

  • DDD는 명확하게 Bounded Context 내에서 보편언어를 모델링 하는 것에 대한 것
  • Bounded Context 는 의미적으로 동일한 컨텍스트의 범위로 표현되며 그 범주 내에 소프웨어 모델의 각 컴포넌트는 특정한 의미, 일을 수행

  • 보편 언어는 바운디드 컨텍스트 안에서 기능하는 소프트웨어 모델을 만드는 모든 구성원이 사용하는 언어 반영

  • 핵심 도메인
    • 바운디드 컨텍스트 안의 모델의 개념으로 조직의 핵심 전략적 계획으로 개발되며 가치 있는 걸들을 달성하는 수단으로 가장 중요한 모델
    • 점점 더 많은 개념이 계속 추가되다 보면 커다란 문제로 발전한다
      • 경계가 제한되지 않은 모델 안에 너무 많은 개념이 존재하게 된다
      • 이를 진흙덩어리라고 하며 이는 도메인 전문가의 소통 부재로 발생할 수 있다
  • 아키텍처
    • Input Adaptor - App Service - Domain Model - Output Adaptor

chap03. 서브 도메인과 전략적 설계

  • DDD 프로젝트 내에는 다수의 바운디드 컨텍스트가 존재
    • 그 중 핵심인 바운디드 컨텍스트가 핵심 도메인
    • 그 외에는 서브 도메인이 된다
  • 서브 도메인이란?
    • 전체 비즈니스의 하위 부분
    • 서브 도메인이 하나의 논리적인 도메인 모델을 나타내는 것이라고 생각할 수 있다
      • 거대한 프로젝트에서 문제 영역을 이해할 수 있도록 전체 비즈니스 도메인을 논리적으로 쪼개어 서브 도메인으로 사용할 수도 있다
  • 서브 도메인 유형
    • 핵심 도메인
      • 전략적 투자 영역, 주요 자원을 할당하는 명시적인 바운디드 컨텍스트
    • 지원 서브 도메인
      • 이미 존재하는 제품으로 해결할 수 없는 맞춤 제작 개발이 필요한 모델링 영역
    • 일반 서브 도메인
      • 기존 제품 구매를 통해 바로 충족 가능한 경우
  • 복잡성 다루기
    • 레거시 안에는 많은 논리적 도메인모델이 존재한다면 서브 도메인으로 생각하자
    • 논리적 도메인을 나누면 큰 시스템의 복잡도를 해결할 수 있다
      • 여러 개의 바운디드 컨텍스트를 사용해 개발한 시스템처럼 보일수도 있다
    • DDD 안에서는 바운디드 컨텍스트와 서브도메인을 1:1 관계를 맺어야 한다
      • 바운디드 컨텍스트를 유지시키고 핵심 전략 목표에 집중하는 것에 도움이 된다

chap04. Context Mapping 과 전략적 설계

  • 컨텍스트 매핑은 다른 바운디드 컨텍스트를 통합해야 하는 경우 해당 바운디드 컨텍스트 사이의 동기/비동기 통신과 가은 방법으로 매핑되어 있는 것
  • 컨텍스트 사이에 관계 정의 등이 필요하다
  • 컨텍스트 매핑 종류
    • 파트너십
      • 팀 당 하나의 바운디드 컨텍스트를 책임지며 의존성을 맞춘다
    • 공유커널
      • 두개 팀 사이에 작지만 공통인 모델 공유
    • 고객/공급자
    • 준수자
  • 컨텍스트 매핑 활용
    • RPC
    • Rest API
    • Messaging

chap05. Aggregate와 전술적 설계

  • Aggregate 형태
    • Aggregate Root -> entity / value object
    • Aggregate 는 1개 이상의 Entity 로 구성되고 그 중 하나가 Aggregate Root 라고 하며 그 구성에 값 객체가 포함될 수 있다
  • Aggregate는 일관성 있는 트랜잭션 경계를 형성
    • Aggregate 내의 구성요소는 비즈니스 규칙에 따르며 일관성 있게 처리되어야 한다
    • 트랜잭션 경계는 비즈니스 때문인데 Aggregate이 유효한 상태인지 아닌지를 결정하는 것이 비즈니스이기 때문이다
  • Aggregate 설계 법칙
    • 경계 내의 비즈니스 불변사항을 봏
      • 트랜잭션이 커밋될 때 비즈니스의 일관성이 지켜지는 것에 기반을 두고 Aggregate 구성 요소 결정 필요
    • 작은 Aggregate을 설계하라
      • Aggregate의 메모리 사용량과 트랜잭션 범위가 비교적 작아야 한다
      • Aggregate를 설계할 때에는 SRP, 단일책임원칙을 고려하자
    • 오직 식별자로만 다른 Aggregate 를 참고하자
      • Aggregate 들은 필요한 다른 Aggregate을 참고할 때 식별자로만 참고해야 한다
      • 이것은 Aggregate 을 작게 유지하고, 동일한 트랜잭션 내에 여러 Aggregate을 수정하려는 접근을 방지
    • 결과적 일관성을 사용하여 다른 Aggregate 을 갱신
      • 도메인 이벤트는 Aggregate에서 발행하고 이에 관심있는 Bounded Context 는 이를 전달 받는다
      • 메시징 메커니즘을 통해 도메인 이벤트를 전달할 수 있다 (결과적 일관성)

chap06. 도메인 이벤트와 전술적 설계

  • 도메인 이벤트는 Bounded Context 내에 비즈니스 관점에서 중요한 사항 들에 대한 기록
  • 도메인 이벤트가 도메인 모델에 구체화되고 도메인 이벤트가 만들어지면 바운디드 컨텍스트와 다른 자원들은 이벤트를 받아 활용
  • 도메인 이벤트 설계/구현/사용
    • 도메인 이벤트 이름은 보편 언어를 반영해야 한다
      • 주로 과거형 동사 사용(ex. ProductCreated)
    • 도메인 이벤트 프로퍼티
      • 이벤트가 만들어지는 시점에 명령이 제공하는 모든 프로퍼티를 담고 있어야 한다
    • 이벤트 발생 인과관계
      • 분산 환경에서 발생한 인과관계 순서가 동일한 순서로 도달하는 것이 보장되지 않는다
      • 적절한 인과관계를 파악하는 것이 소비 바운디드 컨텍스트에 역할
      • 시퀀스, 이벤트, 메타 Data
  • Event Sourcing
    • Aggregate Instance 변경된 것에 대한 기록
    • 상태 전체를 저장하는 것이 아닌 도메인 이벤트를 모두 저장
    • Event Stream 을 구성하여 Event가 발생하면 마지막에 추가
    • 높은 처리량, 낮은 대기시간, 높은 확장성이란 장접

출처

  • 책 / 반 버논 저자의 도메인 주도 설계