Tackling Complexity in the Heart of Software

복잡한 도메인(문제 영역)을 이해하고 모델링하고, 공통 언어로 소통하는데 초점을 맞추는 방법론.

• DDD는 모델을 동작하게 만들어 애플리케이션의 문제를 해결한다.^p.62
  • 지식 탐구 → Ubiquitous Language 사용 → (단일) 모델 생성 → 모델과 구현을 밀접하게 연관 시킴
• DDD의 목표는 기술보다는 도메인에 대한 모델에 집중해 더 나은 소프트웨어를 만들어내는 것이다.^p.154

본문 내용 출처 : Eric Evans. 『도메인 주도 설계』. 이대엽(역). 위키북스, 2011.

Part I: Putting the Domain Model to Work

대개 컴퓨터와 관련 없다

• 사용자가 프로그램을 사용하는 대상 영역
  • 사용자의 활동
  • 사용자의 관심사

도메인 지식의 부담을 해소하기 위한 도구

• 대상을 단순화 한 것
  • 어떤 사실을 해석한 것
  • 당면의 문제를 해결하는 것과 관련된 측면으로 추상화
    • 그 밖의 중요하지 않은 세부사항에는 주의를 기울이지 않는다!
• 도메인 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태
• 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식 ^{01 동작하는 도메인 만들기, 4p}
• 프로젝트에 참여한 사람들의 머릿속에 축적된 개념을 모아 놓은 것으로서 도메인에 대한 통찰력을 반영하는 용어와 관계로 표현된다. ^{02 의사소통과 언어 사용, 23p}
  • 관계(relationships) : 모든 언어에 내재된 결합 규칙 ^{02 의사소통과 언어 사용, 26p}

• 특정한 다이어그램이 아니라
  다이어그램이 전달하고자 하는 아이디어
• 도메인 지식을 엄격하게 구성하고 선택적으로 추상화한 것
• 일련의 개념들을 모아놓은 것 ^77p

DDD에서는 아래의 세 가지 기본적인 쓰임새에 따라 모델을 선택한다

• 모델과 핵심 설계는 서로 영향을 주며 구체화된다 (3장 참고)
  • 모델을 의미 있게 만들고
    모델의 분석이 최종 산출물인 동작하는 프로그램에 적용되게끔 보장하는 것은
    모델과 구현 간의 긴밀한 연결
  • 모델을 이해한 바에 근거해 코드를 해석할 수 있기 때문

1. 모델은 모든 팀 구성원이 사용하는 언어의 중추
   • 모델과 구현이 서로 연결 → 개발자와 도메인 전문가간의 번역이 필요하지 않음
2. 모델은 지식의 정수만을 뽑아낸 것이다
   • 모델은 도메인 지식을 조직화하고 가장 중요한 요소를 구분하는 팀의 합의된 방식 → 공유 언어 사용!!

해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력. 그 뿐만 아니라 모델링 기법을 연마해서 도메인 설계에 통달해야 한다.

  대부분의 유능한 개발자는 다뤄야 할 특정 도메인을 학습하는 데 관심이 많지 않으며,
  더군다나 도메인 모델링 기법을 쌓는 데는 더더욱 전념하지 않는다.
  엔지니어들은 자신의 기술력을 훈련할 수 있는 정략적인 문제를 좋아한다.

• 01 지식 탐구
• 02 의사소통과 언어 사용
• 03 모델과 구현의 연계

Part II: The Building Blocks of a Model-Driven Design

• 04 도메인의 격리
• 05 소프트웨어에서 표현되는 모델
• 06 도메인 객체의 생명 주기
• 07 언어의 사용: 확장 예제

Part III: Refactoring Toward Deeper Insight

Levels of Refactoring

Deep Models

Deep Model/Supple Design

The Discovery Process

• 08 도약
• 09 암시적인 개념을 명확하게 만들기
• 10 유연한 설계
• 11 분석 패턴의 적용
• 12 모델에서 디자인 패턴 연결
• 13 더 심층적인 통찰력을 향한 리팩터링

Part IV: Strategic Design

• 14 모델의 무결성 유지
• 15 디스틸레이션
• 16 대규모 구조
• 17 전략의 종합