01부 동작하는 도메인 모델 만들기

  • 도메인 주도 설계에서의 모델의 유용성

  • 소프트웨어의 본질

  • 01장 지식 탐구

    • 효과적인 모델링의 요소
    • 지식 탐구
    • 지속적인 학습
    • 지식이 풍부한 설계
    • 심층 모델

  • 02장 의사소통과 언어 사용

    • UBIQUITOUS LANGUAGE (보편 언어)
    • 크게 소리내어 모델링하기
    • 한 팀, 한 언어
    • 문서와 다이어그램
      • 글로 쓴 설계 문서
      • 실행 가능한 기반
    • 설명을 위한 모델

  • 03장 모델과 구현의 연계

    • MODEL-DRIVEN DESIGN (모델 주도 설계)
    • 모델링 패러다임과 도구 지원
    • 내부 드러내기: 왜 모델이 사용자에게 중요한가
    • HANDS-ON MODELER (실천적 모델러)

02부 모델 주도 설계의 기본 요소

  • 04장 도메인의 격리

    • LAYERED ARCHITECTURE (계층형 아키텍처)
      • 계층 간 관계 설정
      • 아키텍처 프레임워크
    • 도메인 계층은 모델이 살아가는 곳
    • SMART UI(지능형 UI) “안티 패턴”
    • 다른 종류의 격리

  • 05장 소프트웨어에서 표현되는 모델

    • 연관관계
    • ENTITY (엔티티, 참조객체라고도 함)
      • ENTITY 모델링
      • 식별 연산의 설계
    • VALUE OBJECT (값 객체)
      • VALUE OBJECT의 설계
      • VALUE OBJECT를 포함한 연관관계 설계
    • SERVICE(서비스)
      • SERVICE와 격리된 도메인 계층
      • 구성 단위
      • SERVICE에 접근하기
    • MODULE(모듈, 패키지라고도 함)
      • 기민한 MODULE
      • 인프라스트럭처 주도 패키지화의 함정
    • 모델링 패러다임
      • 객체 패러다임이 지배적인 이유
      • 객체 세계에서 객체가 아닌 것들
      • 패러다임이 혼재할 때 MODEL-DRIVEN DESIGN 고수하기

  • 06장 도메인 객체의 생명주기

    • AGGREGATE (집합)
    • FACTORY (팩터리)
      • FACTORY와 FACTORY의 위치 선정
      • 생성자만으로 충분한 경우
      • 인터페이스 설계
      • 불변식 로직의 위치
      • ENTITY FACTORY와 VALUE OBJECT FACTORY
      • 저장된 객체의 재구성
    • REPOSITORY (리파지터리)
      • REPOSITORY에 질의하기
      • 클라이언트 코드가 REPOSITORY 구현을 무시한다 (개발자는 그렇지 않지만)
      • REPOSITORY 구현
      • 프레임워크의 활용
      • FACTORY와의 관계
    • 관계형 데이터베이스를 위한 객체 설계

  • 07장 언어의 사용(확장 예제)

    • 화물 해운 시스템 소개
    • 도메인 격리: 응용 기능 소개
    • ENTITY와 VALUE OBJECT의 구분
      • 역할과 그 밖의 속성
    • 해운 도메인의 연관관계 설계
    • AGGREGATE의 경계
    • REPOSITORY의 선정
    • 시나리오 연습
      • 예제 애플리케이션 기능: 화물의 목적지 변경
      • 예제 애플리케이션 기능: 반복 업무
    • 객체 생성
      • Cargo에 대한 FACTORY와 생성자
      • Handling Event 추가
    • 리팩터링할 시간: Cargo AGGREGATE의 설계 대안
    • 해운 모델의 MODULE
    • 새로운 기능 도입: 할당량 검사
      • 두 시스템의 연계
      • 모델 강화: 업무 분야 나누기
      • 성능 최적화
    • 최종 검토

03부 더 심층적인 통찰력을 향한 리팩터링

  • 리팩터링 수준

  • 심층 모델

  • 심층 모델/유연한 설계

  • 발견 과정

  • 08장 도약

    • 도약에 관한 일화
      • 괜찮은 모델이기는 하지만……
      • 도약
      • 더 심층적인 모델
      • 냉정한 결정
      • 결말
    • 기회
    • 기본에 집중하라
    • 후기 : 연이은 새로운 통찰력의 출현

  • 09장 암시적인 개념을 명확하게

    • 개념 파헤치기
      • 언어에 귀 기울여라
      • 어색한 부분을 조사하라
      • 모순점에 대해 깊이 고민하라
      • 서적을 참고하라
      • 시도하고 또 시도하라
    • 다소 불명확한 개념의 모델링
      • 명시적인 제약조건
      • 도메인 객체로서의 프로세스
    • SPECIFICATION (명세)
      • SPECIFICATION의 적용과 구현

  • 10장 유연한 설계

    • INTENTION-REVEALING INTERFACE (의도를 드러내는 인터페이스)
    • SIDE-EFFECT-FREE FUNCTION (부수효과가 없는 함수)
    • ASSERTION (단정)
    • CONCEPTUAL CONTOUR (개념적 윤곽)
    • STANDALONE CLASS (독립형 클래스)
    • CLOSURE OF OPERATION (연산의 닫힘)
    • 선언적 설계
      • 도메인 특화 언어
    • 선언적인 형식의 설계
      • SPECIFICATION을 선언적인 형식으로 확장하기
    • 받음각
      • 서브 도메인으로 분할하라
      • 가능하다면 정립된 정형화를 활용하라

  • 11장 분석 패턴의 적용

  • 12장 모델과 디자인 패턴의 연결

    • STRATEGY (POLICY라고도 함)
    • COMPOSITE (복합체)
    • 그렇다면 FLYWEIGHT는?

  • 13장 더 심층적인 통찰력을 향한 리팩터링

    • 시작
    • 조사팀
    • 선행 기술
    • 개발자를 위한 설계
    • 타이밍
    • 위기를 기회로

04부 전략적 설계

  • 14장 모델의 무결성 유지

    • BOUNDED CONTEXT (제한된 컨텍스트)
      • BOUNDED CONTEXT 안의 균열 인식
    • CONTINUOUS INTEGRATION (지속적인 통합)
    • CONTEXT MAP (컨텍스트 맵)
      • CONTEXT 경계에서의 테스트
      • CONTEXT MAP의 조직화와 문서화
    • BOUNDED CONTEXT 간의 관계
    • SHARED KERNEL (공유 커널)
    • CUSTOMER/SUPPLIER DEVELOPMENTTEAM (고객/공급자 개발 팀)
    • CONFORMIST (준수자)
    • ANTICORRUPTION LAYER (오류 방지 계층)
      • ANTICORRUPTION LAYER의 인터페이스 설계
      • ANTICORRUPTION LAYER의 구현
      • 교훈적인 이야기
    • SEPARATE WAYS (각자의 길)
    • OPEN HOST SERVICE (공개 호스트 서비스)
    • PUBLISHED LANGUAGE (공표된 언어)
    • 코끼리 통일하기
    • 모델의 컨텍스트 전략 선택
      • 팀 의사결정 또는 그 이상
      • 우리 자신을 컨텍스트에 배치하기
      • 경계의 변형
      • 변경할 수 없다는 사실을 인정하기: 외부 시스템의 묘사
      • 외부 시스템과의 관계
      • 설계 중인 시스템
      • 개별 모델의 특수한 요구사항 충족하기
      • 배치
      • 타협점
      • 프로젝트가 이미 진행 중일 때
    • 변형
      • CONTEXT 병합: SEPARATE WAYS → SHARED KERNEL
      • CONTEXT 병합: SHARED KERNEL → CONTINUOUS INTEGRATION
      • 레거시 시스템의 단계적 폐기
      • OPEN HOST SERVICE → PUBLISHED LANGUAGE

  • 15장 디스틸레이션

    • CORE DOMAIN (핵심 도메인)
      • CORE 선택
      • 누가 그 일을 할 것인가?
    • 디스틸레이션의 단계적 확대
    • GENERIC SUBDOMAIN (일반 하위 도메인)
      • 일반화가 재사용 가능하다는 의미는 아니다
      • 프로젝트 위험 관리
    • DOMAIN VISION STATEMENT (도메인 비전 선언문)
    • HIGHLIGHTED CORE (강조된 핵심)
      • 디스틸레이션 문서
      • 표시된 CORE
      • 프로세스 도구로서의 디스틸레이션 문서
    • COHESIVE MECHANISM (응집력 있는 메커니즘)
      • GENERIC SUBDOMAIN과 COHESIVE MECHANISM
      • MECHANISM이 CORE DOMAIN의 일부인 경우
    • 선언적 형식의 디스틸레이션
    • SEGREGATED CORE (분리된 핵심)
      • SEGREGATED CORE를 만드는 데 드는 비용
      • 발전하는 팀의 의사결정
    • ABSTRACT CORE (추상화된 핵심)
    • 심층 모델의 디스틸레이션
    • 리팩터링의 대상 선택

  • 16장 대규모 구조

    • EVOLVING ORDER (발전하는 질서)
    • SYSTEM METAPHOR (시스템 은유)
      • “미숙한 은유"와 그것이 필요 없는 이유
    • RESPONSIBILITY LAYER (책임 계층)
      • 적절한 계층의 선택
    • KNOWLEDGE LEVEL (지식 수준)
    • PLUGGABLE COMPONENT FRAMEWORK (착탈식 컴포넌트 프레임워크)
    • 구조는 얼마나 제약성을 지녀야 하는가?
    • 잘 맞아떨어지는 구조를 향한 리팩터링
      • 최소주의
      • 의사소통과 자기 훈련
      • 재구조화가 유연한 설계를 낳는다
      • 디스틸레이션은 부하를 줄인다

  • 17장 전략의 종합

    • 대규모 구조와 BOUNDED CONTEXT와의 결합
    • 대규모 구조와 디스틸레이션과의 결합
    • 평가 먼저
    • 누가 전략을 세우는가?
      • 애플리케이션 개발에서 창발하는 구조
      • 고객(애플리케이션 개발팀) 중심의 아키텍처 팀
    • 전략적 설계 결정을 위한 6가지 필수 요소
      • 기술 프레임워크도 마찬가지다
      • 종합계획을 조심하라

  • 결론

  • 맺음말