[keyword] 15장 디스틸레이션

[emiling]

주제

'15장 - 디스틸레이션'을 읽고 내용을 요약하거나,
중요✨ 하다고 생각하는 키워드 및 관련 설명을 코멘트로 달아주세요

연관 챕터

https://github.com/caffeine-library/Domain-Driven-Design/issues/61

[emiling]

폭넓은 일련의 모델을 구분하고 도메인 모델의 정수를 추출하는 방법에 대해 살펴보는 것

CORE DOMAIN

• 설계측면에 우선순위를 매겨 모델의 핵심적인 측면(정수)을 보조적인 기능과 분리해야함
  • 부수적인 요소를 GENERIC SUBDOMAIN으로 분리하여 CORE를 식별하고 이해하기 쉽게 하라 (일반화)
• 어떻게 CORE에 대한 의사소통과 인식을 개선할 수 있지? (정보 제공 및 안내)
  • DOMAIN VISION STATEMENT : 도메인에 대한 방향성 제시
  • HIGHLIGHTED CORE : 도메인 구성요소 사이의 상호작용
• 어떻게 CORE의 모델과 설계 자체를 구조적으로 변경할 수 있는가? (구현)
  • COHESIVE MECHANISM : 계산 매커니즘(어떻게) 부분을 분리하여 의도를 잘 드러내도록 (무엇을) 노출하라
  • SEGREGATED CORE : 보조적인 역할로 부터 CORE의 개념을 분리하고, CORE와 다른 코드 와의 결합은 줄이며 응집도는 강화하라
• ABSTRACT CORE : 모델의 가장 근본적인 개념을 추출하여 추상화 하라
  • 핵심 개념과 시스템의 주요 상호작용에서 수행하는 역할

[leejaeseung]

COHESIVE MECHANISM 은 개념적으로 일관된 ASSERTION 과 SIDE-EFFECT-FREE-FUNCTION 을 지니고 INTENTION-REVEALING INTERFACE 를 통해 접근할 수 있을 때 가장 유용하다.

COHESIVE MECHANISM 이 선언적 프로그래밍과 연관이 있는데, 위 문구가 선언적 프로그래밍을 잘 나타내는 문구인 것 같습니다.

• 일관된 ASSERTION : 예측 가능한 제약 사항
• SIDE-EFFECT-FREE-FUNCTION : 부수 효과가 없는 함수. 즉, 해당 함수를 사용했을 때 함수의 동작 외의 다른 동작이 발생하지 않음을 예측할 수 있는 함수. (참조 투명성)
• INTENTION-REVEALING INTERFACE : 의도가 드러나는 인터페이스. 드러난 의도만으로 해당 인터페이스의 동작이 예측되는 인터페이스. 내부 구현을 들여다보지 않아도 된다. (선언적)

[JasonYoo1995]

디스틸레이션 (Distillation)

• 정제된 모델 중에서도 더 핵심 부분을 추출하는 과정

  핵심 도메인 (Core Domain)

• 모델의 중심적이고 핵심적인 부분
• 나머지 덜 중심적인 부분과 분리되어야 한다
• 핵심 개발자가 핵심 도메인을 맡아야 한다
• Core를 선택하는 방법
  • 한 번에 알기 어려울 수 있다
  • 일반 하위 도메인이 아닌 것으로 구분할 수 있다
• 구현 방법
  • 기성 솔루션 구입 → 비추천
  • 외주 → 비추천
  • 사내 제작 → 추천

    일반 하위 도메인 (Generic Subdomain)

• 재패키지화를 통해 별도의 Module로 분리
• 보조적 역할
• Core보다 낮은 우선순위로 리소스 투자
• Generic Subdomain은 Core Domain에 대한 심층적인 이해 없이 독립적으로 개발할 수 있게 해줘, 교육 부담 비용을 줄여 준다
  • 예시
    • 상품 관리 서버 개발팀
    • 결제 서버 개발팀
    • 결제 검증 서버 개발팀
      • 결제 검증 파트
      • 포인트 적립 연동 파트
    • 상품 지급 서버 개발팀
    • 결제 건에 대한 포인트 적립 서버 개발팀
    • 포인트 후원 서버 개발팀
• 구현 방법
  • 기성 솔루션 구입
  • 외주
  • 공표된 모델을 모방
  • (핵심 도메인 처럼) 순수하게 사내 제작을 할 수도 있다
• 구현 예시
  • (PG사 연결된) 기성 솔루션 이용하는 경우
    • 모바일 결제 : 구글 플레이 스토어 / 앱스토어
    • PC 결제 : PG사 결제 시스템
    • 웹사이트 결제 : Mycard
    • 콘솔 결제 : Play Station 마켓 / XBox 마켓
  • (PG사를 직접 연결해서) 사내 제작하는 경우
    • PC 결제 : 사내 결제 서버

      도메인 비전 선언문 (Domain Vision Statement)

• 도메인의 내용을 요약하고 해당 도메인이 기업에게 주는 자산으로서의 가치를 선언
• 자원 할당의 판단 기준
• 적은 투자로 Core에 대한 의사소통 비용 절약
  • 신규 인원에 대한 교육
  • 신규 기능에 대해 프로젝트 이해관계자들을 만족시켜주는 근거로서 활용

    강조된 핵심 (Highlighted Core)

• Module이 이미 Core Domain을 나타내지만 강조된 핵심은 Core Domain을 나타내는 좀 더 직접적이고 적극적인 수단
• Core Domain을 별도의 Module로 분리하는 데에 사용하는 지침이 될 수 있음
• 적은 투자로 Core에 대한 의사소통 비용 절약
• 디스틸레이션 문서
  • Core Domain의 윤곽을 최소주의적으로 기술하고 설명하는 문서
  • UML 클래스 / 시퀀스 다이어그램 / 비표준 다이어그램
  • 예시
    • 결제 수단별 시퀀스 다이어그램을 하나의 문서에 통합하여 관리
    • 팀 논의 시 해당 다이어그램을 띄워놓고 논의

      응집력 있는 메커니즘 (Cohesive Mechanism)

• 무엇(what)과 어떻게(how)를 분리
  • 무엇 : Core Domain (선언적)
  • 어떻게 : Cohesive Mechanism (절차적)
    • 복잡한 연산을 캡슐화
• 예시
  • 모든 결제 수단이 Flow(=what)는 같으나 결제 수단마다 세부 구현(=how)은 다름
    • 기본 Flow : 시작 → 결제 → 검증 → 지급
    • 복구 Flow : 복구 → 검증 → 지급
  • 시작/결제/검증/지급/복구 : what
    • 결제 수단별로 별도의 클래스로 분리하였으나 각 클래스의 메서드 네이밍은 what의 의미를 지니는 비슷한 이름

      분리된 핵심 (Segregated Core)

• 보조적인 요소들로부터 분리된 Core
  • 도메인 비전 선언문 (Domain Vision Statement)에 의거해 재패키지화
• Core Domain의 응집성이 높아지고, 코드 상에서 Core에 대해 이해하기 더 쉬워진다
• 예시 : 아래 재패키지화 과정에서 ‘배송’ 패키지가 Segregated Core

추상화된 핵심 (Abstract Core)

• Core Domain 자체만으로 복잡하므로, 이해할 수 있는 규모로 더 분리
• 다형적 인터페이스 관점으로 분리 (수평으로 자르기)
  • 별도의 Class로 추출
  • Abstact Class로 추출
  • Interface로 추출
• 수직(=Vertical)으로 자르기 vs 수평(=Horizontal)으로 자르기
• 예시
  • 수직으로 자르기 : ‘시작 → 결제 → 검증 → 지급’의 Flow를 4개로 분리
  • 수평으로 자르기 : 결제 수단별로 분리
  • 리팩토링 예시
    • 모든 결제 수단이 하나의 ‘시작’ 메서드를 참조하고 있었고 ’시작’ 메서드 안에서 if문으로 결제 수단을 구분하고 있었다
    • 결제 수단별로 각자의 ‘시작’ 메서드를 갖도록 수정