DDD

1. 도메인 주도 설계란?

• 도메인 주도 설계란 계속 진화하는 소프트웨어를 만들어내기 위한 개념과 설계 방식을 에릭 에반스의 지식과 경험을 토대로 정리한 것입니다.

1.1 도메인이란?

• 도메인이란 소프트웨어가 대상으로 하는 영역입니다.
• 업무용 애플리케이션이라면 비즈니스 활동 자체가 도메인입니다.

1.2 도메인 주도 설계의 목표

• 일반적인 소프트웨어 개발은 아래와 같은 V 모델을 따릅니다.
• 도메인 주도 설계의 목표는 V 모델의 최상위의 비즈니스와 최하위의 소프트웨어를 직접적으로 강하게 연결하는 것입니다.
• 또한 도메인 주도 설계는 비즈니스 환경이 변하고 발전하는 동안에도 계속해서 존속하는 것을 목표로 합니다.

V 모델

V 모델은 폭포수 모델을 확장한 소프트웨어 개발 방법론입니다. V자 형태로 왼쪽에는 분석/설계 단계(요구사항 분석 → 시스템 설계 → 상세 설계 → 구현), 오른쪽에는 테스트 단계(단위 테스트 → 통합 테스트 → 시스템 테스트 → 인수 테스트)가 배치됩니다. 각 개발 단계마다 대응하는 테스트 단계가 있어, 검증과 확인이 체계적으로 이루어집니다.

1.3 도메인 주도 설계의 특징

• 93p
• 에릭 에반스의 도메인 주도 설계 서문에 따르면, 도메인 주도 설계의 특징은 다음의 세 가지입니다.
  • 복잡한 업무 로직에 초점을 맞춘다.
  • 모델에 기반해서 설계한다
  • 리팩터링을 자주 수행한다.

2. 도메인 주도 패턴

• 유비쿼터스 언어
• 경계 컨텍스트
• 값 객체
• 애그리게이트
• 리포지터리

3. 도메인 모델

• 도메인 주도 설계에서 복잡한 업무 규칙이 적용된 소프트웨어를 쉽고 안전하게 변경하기 위해 어떤 기법을 사용할까요?
• 그 중심이 바로 도메인 모델입니다.
• 모델은 방대한 정보 중에서 핵심을 단순하고 알기 쉽게 정리한 구조입니다.
• 도메인 모델은 소프트웨어의 대상 영역(도메인)인 비즈니스 활동의 복잡한 부분을 요점으로 정리하고 단순화한 것입니다.

3.1 도메인 모델의 용도

• 도메인 모델은 복잡한 업무 규칙을 소프트웨어로 표현하기 위한 도구로, 다음 세 가지 용도로 사용합니다.
  • 업무 지식의 요점 정리
  • 개발 활동에서 의도를 전달하는 기본 용어
  • 클래스 설계의 골격

4. 유비쿼터스 언어

• 유비쿼터스는 언제 어디서나라는 의미의 단어입니다.
• 업무 전문가와 소프트웨어 개발 전문가가 서로 다른 용어를 사용하는 것이 아니라, 소프트웨어 개발의 다양한 활동을 통해 일관되게 같은 용어를 사용해 소프트웨어를 개발하자라고 하는 것이 유비쿼터스 언어입니다.
• 하지만 개발 업무에 따라 사용되는 용어의 수는 방대합니다.
  • 이 모든 용어를 찾아 정의하는 방식은 현실적이지 않습니다.
  • 우선 당면한 과제의 중요한 용어를 선별합니다.
  • 선별한 용어를 의식적으로 사용하면, 그 용어가 중심이 되어 그 주변 용어도 일치하게 됩니다.
  • 이렇게 중심이 되는 용어들의 집합이 바로 도메인 모델입니다.
• 유비쿼터스 언어는 대화에서만 사용되는 것이 아니라, 소스 코드의 클래스 이름이나 메서드 이름, 커밋 로그 등에도 사용되기 때문에 유비쿼터스라고 부릅니다.
• 110p
  • 도메인 주도 설계에서 유비쿼터스 언어는 아래와 같은 용도로 사용됩니다.
    • 시스템의 결과물인 코드를 설명한다.
    • 작업이나 기능을 표현한다.
    • 개발자와 도메인 전문가가 의사소통한다.
    • 도메인 전문가끼리 요구사항이나 개발 계획 또는 기능을 표현한다.

4.1 대화에 자주 사용되는 용어만 정의한다.

-123p

• 일단 유비쿼터스 언어를 정의하기 시작하면 어느 범위 까지 적용해야될지 고민
• 대화에 자주 사용되는 용어만 정의하고, 자주 사용되지 않는 용어는 정의하지 않는 것이 좋습니다.
• 유비쿼터스 언어로 지정할지는 유스케이스나 이와 유사한 문서에 등장하는 주요 개념을 기준으로 삼는 것이 타당

5. 업무 규칙

5.1 업무 규칙이란? (p038)

• p038
  • 업무 규칙을 적용한 소프트웨어를 구현하기 위해 도메인 모델을 만듭니다.
  • 업무 규칙을 이해하는 데 필요한 기초 지식을 쌓으려면 다음과 같은 관점에서 비즈니스 활동을 파악하는 것이 유용합니다
    • 가치 제공의 대가
    • 약속과 실행
    • 매출과 비용
    • 시장에서의 경쟁과 비즈니스의 생존 가능성
• p93
  • 업무 규칙이란 업무 목표를 달성하기 위한 행동을 통제하고 결정하기 위한 것입니다.
  • 매출 최대화와 비용 최소화를 위해, 적절한 행동을 자극하고 부적절한 행동은 제한하는 다양한 규칙입니다.
  • 업무 규칙은 비즈니스 활동에 포함됩니다.
  • 이것을 소프트웨어로 구현한 것이 업무 로직입니다.
  • 업무 로직이란 업무 규칙에 따라 정의된 작업을, 소프트웨어로 구현한 업무 규칙이라고 할 수 있습니다.

5.2 가치 제공의 대가 (p039)

5.3 약속과 실행

5.4 매출과 비용 (p041)

6. 애그리게이트

• p90
  • 도메인 모델을 구성하는 요소 중 애플리케이션에 필요한 계산과 판단 서비스를 제공하는 것은 주로 애그리게이트입니다. (p090)
    • 애그리게이트로 계산과 판단을 수행하는 클래스를 애플리케이션 서비스 또는 유스케이스라고 합니다.
    • 애플리케이션 서비스는 팩토리 패턴이나 리포지터리 패턴을 사용해 필요한 애그리게이트를 얻고, 그 애그리게이트를 사용해 계산과 판단을 실행하며, 필요에 따라서 계산과 판단의 결과를 리포지터리에 저장합니다.
• p102
  • 애그리게이트는 복잡한 업무 로직을 표현하는 수단입니다.
  • 업무 데이터와 업무 로직을 캠슐화한 각각의 값 객체들을 결합하여 복잡한 업무 로직을 표현하는 클래스가 바로 애그리게이트입니다.

7. 팩토리

• 팩토리는 복잡한 애그리게이트를 생성하는 책임을 애그리게이트로부터 분리하기 위한 패턴입니다. (p090)
  • 애그리게이트는 복잡한 업무 규칙에 기반한 계산과 판단 로직을 구현한 객체입니다.
  • 복잡한 계산과 판단 로직을 구현하기 위해 다양한 값 객체들을 내부에 포함하면서 구조가 복잡해지는 경우가 많습니다.
  • 팩토리는 이렇게 복잡한 애그리게이트를 조립할 수 있게 분리한 패턴입니다.
  • 애그리게이트가 본래의 역할에 집중할 수 있도록 애그리게이트를 생성하는 로직을 따로 분리한 패턴입니다.

7. 경계 컨텍스트

• 하나의 도메인 모델이 다루는 범위를 제한하는 접근 방식입니다.

7.1 컨텍스트 구분 방법

• 도메인 모델에서 용어가 하나의 의미를 갖는 범위는 다음과 같은 네 가지 요소에 크게 영향을 받습니다.
  • 팀
  • 요구사항의 출처
  • 소스코드 관리
  • 데이터 소유권

8. 컨텍스트 맵

• 각각의 경계 컨텍스트 안에서만 의미를 갖는 여러 도메인 모델들을 어떻게 연결할 것인가를 고민하기 위한 패턴입니다.
• 이러한 경계 컨텍스트를 구성 요소로 하는 전체 네트워크를 컨텍스트 맵이라고 합니다.

9. 핵심 도메인

• 비즈니스 영역 전체에 도메인 주고 설계 방식을 적용하는 것은 현실적이지 않습니다.
• 비용 대비 효율적인 방법을 고민하는 것도 전략전 설계의 중요한 과제입니다. 이것이 바로 핵심 도메인에 집중한다라는 설계 방식입니다.

9.1 핵심 도메인 식별

• 업무 로직의 복잡성: 업무 프로세스와 업무 규칙의 복잡성
• 업무의 교유성: 자사만의 고유한 업무 방침을 가지는 것이 중요한지, 아니면 타사와 동일한 방식이어도 상관없는지?
• 이 두 축을 조합하여 네 개의 영역으로 나누면, 복잡한 업무와 자사의 독자적인 업무 두 가지가 결합된 영역이 핵심 도메인이 됩니다.

10. 분산 아키텍처

• 모놀리스
• 모듈러 모노리스
• 마이크로 서비스 아키텍처

11. 모델

• 95p
  • 도메인 주도 설계에서는 복잡한 업무 로직을 이해하고 정리하는 수단으로 모델을 만듭니다.
  • 소프트웨어를 만들기위한 모델은 두 가지로 분류할 수 있습니다.
  • 하나는 업무 내용이나 요구사항을 이해하기 위한 분석 모델입니다.
  • 다른 하나는 소프트웨어를 실제로 만들기 위한 설계 모델입니다.
  • 도메인 주도 설계는 분석 모델과 설계 모델을 일치시키는 것을 중시합니다.

12. 도메인 주도 설계의 설계 기법

• 96p
  • 도메인 주도 설계의 기법은 전략적 설계와 전술적 설계 두 가지로 분류할 수 있습니다.
  • 전략적 설계와 전술적 설계는 서로 보완하는 관계입니다.
  • 전략적 설계는 넓은 시야에서 모델을 만드는것을 중요하게 생각합니다.
  • 전략적 설계의 대표적인 예는 유비쿼터스 언어, 경계 컨텍스트, 컨텍스트 맵, 핵심 도메인입니다.
  • 전술적 설계는 복잡한 업무 로직을 소프트웨어 기법으로 표현하기 위한 기법으로 실제 소스 코드를 구현하기 위한 기술적인 측면에 가까울 설계 기법입니다.
  • 대표적인 기법으로 엔티티, 값 객체, 애그리게이트, 모듈, 도메인 이벤트, 리포지터리가 있습니다.
• 97p
  • 경량 DDD는
  • 기술적인 관점으로 전술적 설계를 도입한다.
  • 전술적 설계의 극히 일부를 적용한다.
  • 전략적 설계에 전념하지 않는다.

12. 값 객체

• 100p
  • 이처럼 업무 규칙을 기술하기 위한 용어가 유비쿼터스 언어이며, 이러한 기본 용어를 소프트웨어로 표현한 것이 값 객체입니다.

13. 모듈

• 106p

14. 리포지토리

• 107p
  • 리포지토리는 객체를 저장하는 구조를 추상적으로 표현한 것입니다.
  • 리포지토리는 업무 로직을 표현하지 않기 때문에 데이터베이스 조작이나 객체 생성에 대한 자세한 내용을 알 필요가 없습니다.
  • 두 가지 설계 방식이 있습니다.
    • 애그리게이트의 최신 상태 유지와 업데이트
    • 저장과 참조의 분리

15. 유스케이스

• 121p
  • 유스케이스는 사용자를 주체로 했을 때 시스템으로 어떤 액션을 취할 수 있는지를 표현한 것입니다.
• 177p
  • 사용자가 사용할 수 있는 응용 프로그램의 기능들은 대부분 유스케이스에 해당합니다.
  • 유스케이스는 업무 로직을 사용할 수 있는 흐름이고, 엔티티는 업무 로직을 담고 있는 객체입니다.

16. 이벤트 스토밍

• 125p
  • 이벤트 스토밍은 도메인 주도 설계의 공통된 도메인 모델을 위한 워크숍입니다.
  • 이는 시스템 개발과 거리가 먼 도메인 전문가는 물론 프로젝트와 관련된 누구나 쉽게 참여할 수 있도록 고안된 기법입니다.

16.1 이벤트 스토밍 개요

• 126p
  • 이벤트 스토밍의 프로세스는 크게 세 가지 단계로 나뉩니다.
  • 빅피처
    • 도메인 내에서 발생하는 다양한 이벤트를 큰 틀에서 식별하고 시간순으로 정렬합니다.
  • 비즈니스 프로세스
    • 이벤트들을 구체적으로 연계시켜야 합니다.
    • 이벤트를 연결하는 명령, 정책, 외부 시스템, 애그리게이트를 명확하게 정의하고 연계해야 비즈니스 전체 흐름을 이해할 수 있습니다.
  • 소프트웨어 시스템 모델링
    • 실제 소프트웨어 시스템을 설계합니다.
    • 애그리게이트에 대해서 깊게 분석하고 경계 컨테그트를 식별함으로써 도메인 모델을 소프트웨어 설계에 적용하는 방법을 연구합니다.

16.1 이벤트 스토밍을 통한 모델링

• 125p

16.2 빅피처

• 128p
• 이벤트 쓰기
• 이벤트는 타임스탬프가 찍힌 과거형
• 이벤트를 시간순으로 정렬한다.
• 해피 해스와 핫 스팟으로 중심을 잡는다.

16.3 비즈니스 프로세스 모델링

• 이벤트와 이벤트를 연결한다.
• 명령
  • 각 이벤트는 그 자체로 발생하는 것이 아니라 시스템이나 프로세스에 대한 구체적인 지시나 동작을 나타내는 명령에 의해 발생합니다.
• 애그리게이트
  • 명령과 이벤트는 직접적으로 연관되어 있지 않으며 명령을 전달하는 매개체를 통해 이벤트가 발생합니다.
  • 애그리게이트는 명령을 전달하는 매개채로 실제 이벤트를 발생시키는 역할을 합니다.
• 외부 시스템
• 정책
  • 정책은 이벤트와 명령을 연결시키는 중요한 요소로, 특정 이벤트가 발생했을 떄 명령이 자동으로 실행되게 사전에 정해 놓은 규칙을 말합니다.
• 액터를 매개로 이벤트 연결하기
  • 액터와 리드 모델
• 조건 분기
• 새드 패스 작성하기
• 애그리게이트로 명명하기
• 유비쿼터스 언어의 형성을 촉진

16.4 소프트웨어 시스템 모델링

• 참여자 변경
• 애그리게이트의 정의와 심층 분석 140p
  • 먼저 실시간으로 일관성이 요구되는 단위로서 애그리게이트를 정의해 나갑니다.
  • 일관성이란 어떤 상황에서도 항상 유지되어야하는 한결같은 특성입니다.
  • 예를 들어 전자상거래 시스템의 장바구니의 금액의 합계를 항상 상품의 수량과 단가를 곱한 일정한 값이됩니다.
  • 이런 경우 장바구니를 애그리게이트로 정의하고 관리하는 것이 좋습니다.
• 남겨야 할 다이어그램에 대하여
• 컨텍스트의 발견 141p
  • 여기서 말하는 컨텍스트는 경계 컨텍스트를 의미합니다.
  • 시스템이나 비즈니스 프로세스의 특정 부분이나 언어의 범위를 정의하는 그룹으로 전체 시스템에서 특정 도메인 모델이 적용된 범위를 나타낸 것입니다.
  • 컨텍스트를 구분하기 위해서는 선을 활용합니다.

17. 이벤트 소싱

17.1 이벤트 스토밍 다이어그램 사례

17.2 이벤트를 전제로 하지 않는 구현 146p

• 전통적인 구현
• 전통적인 구현의 문제점
• 개인의 능력에 따라 달라지는 해석
• 다이어그램 구현과의 괴리

17.3 이벤트 중심의 구현

• 이벤트 소싱이란?
• 프레임워크를 활용한 구현

17.4 이벤트 소싱을 통한 구현

17.5 이벤트 스토밍과 이벤트 소싱

17.6 인프라 스트럭처 구현

18. 클린 아키텍처

• 174p
  • 응집도란 서로 관련된 구성 요소들이 서로 가까이 뭉쳐 있거나, 관계가 약한 구성 요소가 서로 떨여지 있는 정도를 말합니다.
  • 이를테면, 데이터베이스와 잘 통신하는지에 대한 관심은 웹 페이지 UI에 관한 관심과는 관계가 멉니다.
  • 그래서 이런 경우의 구현은 완전히 다른 그룹(패키지 혹은 컴포넌트)에 속하는 것이 보통입니다.
• 175p
  • 응집도를 고려하여 그룹을 잘 나눴다고 하더라도 또 다른 요인이 따라 그룹들이 얽히는 경우가 있습니다.
  • 느슨합 결합은 코드를 변경하지 않아도 연결된 대상을 바꿀 수 있으며, 강한 결합은 코드를 직접 변경해야 연결된 대상을 바꿀 수 있습니다.
• 175p
  • 의존성이란 하나의 구성 요소가 다른 구성 요소에 기대서 동작하는 관계를 의미합니다.
  • 의존하는 모듈을 변경하면 여기에 의존하고 있던 모듈이 제대로 동작하지 않을 수 도 있습니다.
• 176p
  • 원의 안쪽으로 향하고 있는 화살표 방향은 계층 간 의존 방향을 나타내느 것입니다.
  • 바깥쪽은 안쪽의 것이 필요하지만, 안쪽에서는 바깥쪽의 것이 필요하지 않습니다.
  • 엔티티는 클린 아키텍처 다이어그램 가장 안쪽에 있습니다.
  • 엔티티라고 하면 흔히 데이터베이스에서 사용하는 엔티티를 생각할 수 있습니다.
  • 하지만 여기서 말하는 에닡티는 철학의 존재론에서 말하는 그 자체로 존재한느 것이라고 이해하면 좋습니다.
  • 단순한 데이터로서의 개체가 아니라 사용자(User)처럼 그 자체의 존재로 의미있는 하나의 요소입니다