[목 차]

옮긴이 머리말 xii

추천사 xv

베타리더 후기 xvi

한국어판 서문 xviii

서문 xix

 

PART I 도메인 이해하기

CHAPTER 1 DDD 소개 3

1.1 공유 모델의 중요성 4

1.2 비즈니스 이벤트로 도메인 이해하기 7

__1.2.1 이벤트 스토밍으로 도메인 탐색하기 8 / 1.2.2 도메인 탐색하기: 주문 접수 시스템 8 / 1.2.3 끄트머리까지 이벤트 확장하기 12 / 1.2.4 명령 문서화하기 13

1.3 도메인을 하위 도메인들로 나누기 15

1.4 경계 진 맥락을 활용한 설루션 만들기 17

__1.4.1 맥락 바로잡기 18 / 1.4.2 맥락 지도 만들기 19 / 1.4.3 가장 중요한 맥락에 집중하기 21

1.5 공용어 만들기 21

1.6 DDD 개념 요약 22

1.7 마무리 23

__1.7.1 이벤트와 프로세스 23 / 1.7.2 하위 도메인과 경계 진 맥락 24 / 1.7.3 공용어 24 / 1.7.4 다음 장 안내 24

 

CHAPTER 2 도메인 이해하기 25

2.1 도메인 전문가 인터뷰하기 25

__2.1.1 비기능적 요구사항 이해하기 27 / 2.1.2 작업 흐름의 나머지 부분 이해하기 28 / 2.1.3 입력 생각해보기 29

2.2 데이터베이스 중심 디자인 지양하기 30

2.3 클래스 중심 디자인 지양하기 31

2.4 도메인 문서화 32

2.5 주문 접수 작업 흐름을 깊이 파고들기 33

2.6 복잡미묘한 도메인 모델링하기 36

__2.6.1 제약 사항 표현하기 37 / 2.6.2 주문의 생애 주기 표현하기 39 / 2.6.3 작업 흐름의 단계 구체화하기 41

2.7 마무리 43

__2.7.1 다음 장 안내 44

 

CHAPTER 3 함수형 아키텍처 45

3.1 경계 진 맥락을 자율적인 소프트웨어 컴포넌트로 46

3.2 경계 진 맥락 간의 소통 47

__3.2.1 경계 진 맥락 간 데이터 전송 48 / 3.2.2 신뢰 경계와 검증 49

3.3 경계 진 맥락 간의 계약 50

__3.3.1 부패 방지 계층 51 / 3.3.2 맥락 간 관계를 나타내는 맥락 지도 51

3.4 경계 진 맥락의 작업 흐름 52

__3.4.1 작업 흐름 입력 및 출력 53 / 3.4.2 경계 진 맥락 내 도메인 이벤트 금지 54

3.5 경계 진 맥락의 코드 구조 55

__3.5.1 양파 아키텍처 56 / 3.5.2 외부 입출력을 맥락 경계로 내몰기 57

3.6 마무리 57

__3.6.1 다음 장 안내 58

 

PART II 도메인 모델링하기

CHAPTER 4 타입 이해하기 61

4.1 함수 이해하기 61

__4.1.1 함수 이해하기 62

4.2 타입과 함수 63

4.3 타입 합성 66

__4.3.1 AND 타입 67 / 4.3.2 OR 타입 67 / 4.3.3 단순 타입 69 / 4.3.4 대수적 타입 시스템 69

4.4 TypeScript 및 Kotlin 타입 다루기 70

4.5 타입으로 도메인 모델 만들기 73

4.6 없어도 되는 값, 오류 및 컬렉션 모델링 77

__4.6.1 없어도 되는 값 모델링 78 / 4.6.2 오류 모델링 79 / 4.6.3 값 자체가 없음 모델링 80 / 4.6.4 리스트 및 컬렉션 모델링 81

4.7 마무리 83

 

CHAPTER 5 타입으로 도메인 모델링하기 85

5.1 도메인 모델 다시 보기 85

5.2 도메인 모델 속 패턴 찾기 87

5.3 단순값 모델링 87

__5.3.1 래퍼 타입 활용하기 89 / 5.3.2 제약 있는 값 90 / 5.3.3 단순 타입의 성능 문제 완화하기 90

5.4 복잡한 데이터 모델링 92

__5.4.1 레코드 모델링 92 / 5.4.2 잘 모르는 타입 모델링 93 / 5.4.3 선택 타입 모델링 94

5.5 함수로 작업 흐름 모델링하기 95

__5.5.1 복잡한 입력 및 출력 처리 96 / 5.5.2 함수 시그니처에서 효과 문서화하기 99

5.6 정체성에 관하여: 값 객체 100

__5.6.1 값 객체의 같음 102

5.7 정체성에 관하여: 엔터티 103

__5.7.1 엔터티의 ID 103 / 5.7.2 데이터 정의에 ID 포함하기 104 / 5.7.3 엔터티의 같음 106 / 5.7.4 불변성과 정체성 108

5.8 집합체 110

__5.8.1 일관성과 불변성을 책임지는 집합체 112 / 5.8.2 집합체 참조 112

5.9 모두 한데 모으기 115

__5.9.1 다시 생각해보는 도전 과제: 정말 타입으로 문서를 대체할 수 있을까? 119

5.10 마무리 120

 

CHAPTER 6 도메인의 무결성과 일관성 121

6.1 단순값의 무결성 122

6.2 측정 단위 126

6.3 타입 시스템으로 불변성 강제하기 128

6.4 타입 시스템에 비즈니스 규칙 녹이기 128

__6.4.1 잘못된 상태가 생길 수 없게 예시 도메인 수정하기 133

6.5 일관성 135

__6.5.1 단일 집합체 내의 일관성 135 / 6.5.2 다른 맥락 간의 일관성 137 / 6.5.3 같은 맥락의 집합체들 간 일관성 138 / 6.5.4 동일한 데이터를 다루는 여러 집합체 140

6.6 마무리 140

 

CHAPTER 7 파이프라인으로 작업 흐름 모델링하기 141

7.1 작업 흐름 입력 142

__7.1.1 명령을 입력으로 사용하기 143 / 7.1.2 공통 구조 일반화하기 144 / 7.1.3 여러 명령을 단일 타입으로 묶기 145

7.2 상태 집합으로 주문 모델링하기 146

__7.2.1 요구사항 변경에 따라 새 상태 타입 추가하기 149

7.3 상태 기계 149

__7.3.1 왜 상태 기계를 사용할까요? 151 / 7.3.2 TypeScript와 Kotlin으로 간단한 상태 기계를 구현하는 방법 151

7.4 타입으로 작업 흐름의 개별 단계 모델링하기 153

__7.4.1 검증 단계 153 / 7.4.2 가격 책정 단계 156 / 7.4.3 주문 확인 단계 157 / 7.4.4 반환할 이벤트 생성 160

7.5 효과 문서화하기 162

__7.5.1 검증 단계의 효과 162 / 7.5.2 가격 산정 단계의 효과 164 / 7.5.3 주문 확인 단계의 효과 165

7.6 개별 단계로부터 작업 흐름 합성하기 166

7.7 의존을 디자인에 포함시켜야 하나요? 167

7.8 완전한 파이프라인 169

__7.8.1 내부 단계 171

7.9 오래 수행하는 작업 흐름 175

7.10 마무리 176

__7.10.1 다음 장 안내 177

 

PART III 모델 구현하기

CHAPTER 8 함수 이해하기 181

8.1 함수, 함수 어디에나 함수 182

8.2 함수가 주인공 183

__8.2.1 주인공인 함수 184 / 8.2.2 입력으로서 함수 185 / 8.2.3 출력으로서 함수 186 / 8.2.4 커링 187 / 8.2.5 부분 적용 188

8.3 완전 함수 189

8.4 함수 합성 192

__8.4.1 TypeScript와 Kotlin의 함수 합성 193 / 8.4.2 전체 애플리케이션을 함수로 구성하기 195 / 8.4.3 녹록지 않은 함수 합성 196

8.5 마무리 198

 

CHAPTER 9 구현: 파이프라인 조합하기 199

9.1 단순 타입 다루기 200

9.2 함수 타입으로 구현 가이드하기 202

9.3 유효성 검증 단계 구현 204

__9.3.1 유효한 주소 생성 207 / 9.3.2 주문 항목 생성 209 / 9.3.3 함수 어댑터 생성 211

9.4 나머지 단계 구현 214

__9.4.1 승인 단계 구현 218 / 9.4.2 이벤트 생성 220

9.5 파이프라인 단계들 모두 모으기 224

9.6 의존 주입 227

__9.6.1 넘쳐 나는 의존 235

9.7 의존 테스트 237

9.8 조립한 파이프라인 240

9.9 마무리 244

 

CHAPTER 10 구현: 오류 처리하기 247

10.1 Either 타입으로 오류 드러내기 247

10.2 도메인 오류 다루기 249

__10.2.1 타입으로 도메인 오류 모델링하기 251 / 10.2.2 코드를 어지럽히는 오류 처리 253

10.3 Either 타입을 출력하는 함수 연결하기 255

__10.3.1 어댑터 블록 구현 258 / 10.3.2 Either 함수들 관리하기 260 / 10.3.3 함수 합성과 타입 검사 261 / 10.3.4 공통 오류 타입으로 변환 262

10.4 flatMap과 map으로 파이프라인 조립하기 266

10.5 다른 유형의 함수들 이중 선로 모델에 적응시키기 269

__10.5.1 예외 처리 269 / 10.5.2 막다른 길 함수 처리 273

10.6 복잡한 파이프라인 다루기 275

__10.6.1 fp-ts의 do 표기법 275 / 10.6.2 arrow-kt의 either 블록 277 / 10.6.3 arrow-kt의 Raise 콘텍스트 278 / 10.6.4 Either 타입으로 주문 검사하기 282 / 10.6.5 Either 리스트의 유효성 검사 283

10.7 모나드와 기타 개념 286

__10.7.1 애플리케이티브로 병렬 합성하기 287

10.8 비동기 효과 추가하기 287

10.9 마무리 291

 

CHAPTER 11 직렬화 293

11.1 영속화와 직렬화 293

11.2 직렬화를 위한 디자인 294

11.3 작업 흐름에 직렬화 코드 연결하기 295

__11.3.1 경계 진 맥락 간 계약으로서 DTO 296

11.4 완전한 직렬화 예제 297

__11.4.1 JSON 직렬화 라이브러리 래핑하기 301 / 11.4.2 완전한 직렬화 파이프라인 302 / 11.4.3 직렬화 타입의 여러 버전 관리하기 306

11.5 도메인 타입을 DTO로 변환하는 방법 306

__11.5.1 단순 타입 306 / 11.5.2 옵셔널값 307 / 11.5.3 레코드 307 / 11.5.4 컬렉션 308 / 11.5.5 열거형 310 / 11.5.6 튜플 311 / 11.5.7 선택 타입 312 / 11.5.8 맵으로 레코드 및 선택 타입 직렬화 317 / 11.5.9 제네릭 320

11.6 마무리 321

 

CHAPTER 12 영속화 323

12.1 영속화 코드를 가장자리로 밀어내기 324

__12.1.1 입력값을 토대로 한 의사 결정 329 / 12.1.2 리포지터리 패턴은 어디에 있을까요? 330

12.2 갱신 명령과 조회 질의 분리하기 331

__12.2.1 명령-질의 책임 분리 334 / 12.2.2 CQRS와 데이터베이스 분리 336 / 12.2.3 이벤트 소싱 336

12.3 경계 진 맥락마다 독자 데이터 저장소 소유하기 337

__12.3.1 여러 도메인의 데이터를 사용하는 방법 337

12.4 문서형 데이터베이스로 작업하기 339

12.5 관계형 데이터베이스 작업하기 339

__12.5.1 선택 타입을 테이블에 매핑하기 341 / 12.5.2 중첩 타입을 테이블에 매핑하기 344 / 12.5.3 관계형 데이터베이스에서 읽기 345 / 12.5.4 관계형 데이터베이스에서 선택 타입 읽기 352 / 12.5.5 관계형 데이터베이스에 쓰기 355

12.6 트랜잭션 358

12.7 마무리 360

 

CHAPTER 13 깔끔하게 디자인 발전시키기 361

13.1 첫 번째 변경: 배송비 추가하기 362

__13.1.1 관심사 분리로 비즈니스 로직 단순하게 만들기 363 / 13.1.2 작업 흐름에 새 단계 추가하기 364 / 13.1.3 파이프라인에 새 단계를 추가한 또 다른 이유 368

13.2 두 번째 변경: VIP 고객 지원 추가하기 368

__13.2.1 작업 흐름에 새로운 입력 추가하기 371 / 13.2.2 작업 흐름에 무료 배송 규칙 추가하기 373

13.3 세 번째 변경: 프로모션 코드 지원 추가 374

__13.3.1 도메인 모델에 프로모션 코드 추가하기 374 / 13.3.2 가격 책정 로직 변경하기 376 / 13.3.3 GetPricingFunction 구현하기 378 / 13.3.4 주문 항목에 할인 문서화하기 379 / 13.3.5 더 복잡한 가격 체계 381 / 13.3.6 경계 진 맥락 간 계약 수정하기 382 / 13.3.7 주문 인쇄하기 384

13.4 네 번째 변경: 영업시간 제약 추가 384

13.5 추가적인 요구사항 변경 처리하기 386

13.6 마무리 386

13.7 책 마무리 387

 

찾아보기 390

[본 문]

일반적으로 프로그래머가 하는 일이 코드를 작성하는 것이라고 생각하는 경우가 대부분일 것입니다. 하지만 저는 동의하지 않습니다. 프로그래머의 업무는 소프트웨어로 문제를 해결하는 것으로서, 코딩은 소프트웨어 개발의 한 측면일 뿐입니다. 좋은 디자인(설계)과 의사소통은 코딩 못지않게 중요합니다. / 소프트웨어 개발을 요구사항이라는 입력을 받아서 최종 결과를 출력하는 프로세스로 생각해본다면, 여기에도 ‘쓰레기를 넣으면 쓰레기가 나온다(garbage in, garbage out)’는 법칙이 적용됩니다. 불분명한 요구사항이나 잘못된 디자인과 같은 옳지 않은 입력으로는 어떤 코드도 원하는 결과를 생성해내지 못합니다. (3쪽)

 

도메인 모델을 소프트웨어로 어떻게 구현할지 훑어보기엔 적기입니다. 빠른 개발 사이클에서는 종종 도메인 전체를 파악하기도 전에 일부를 먼저 구현해야 하는 경우가 생기기도 합니다. 따라서 구성 요소들을 모두 만들기 전에 이들을 어떻게 결합해야 할지 고민해야 합니다. 전체 시스템이 어떻게 동작할지 보여주는 엉성한 프로토타입, ‘워킹 스켈레톤(walking skeleton)’을 만드는 것에 대해서도 할 얘기가 많습니다. 일찍이 무엇을 어떻게 구현할지 살펴보는 것은 아직 충분히 이해하지 못한 부분을 찾아내는 최선의 방법입니다. (45쪽)

 

지금까지 도메인을 올바르게 모델링하기 위한 노력을 해왔다면, 이제는 도메인의 모든 데이터가 유효하고 일관되도록 몇 가지 예방 조치가 필요합니다. 신뢰할 수 없는 외부 세계와 구분하여 경계 진 맥락 내에서는 신뢰하는 데이터만 있게 할 것입니다. 맥락 내 모든 데이터가 항상 유효하다고 확신할 수 있다면 깔끔한 구현은 물론, 불필요한 방어 코드를 피할 수 있습니다. (121쪽)

 

지금까지 주문 처리 작업 흐름에 대한 요구사항을 파악하고 타입으로 모델링했습니다. 이제 그 디자인을 함수형 프로그래밍 방식으로 구현하는 것이 다음 과제입니다. / 본격적으로 들어가기에 앞서 함수형 프로그래밍이 무엇인지, 그리고 구현을 위해 필요한 도구와 전략을 이해하는 것이 중요합니다. 이 장을 마치면 함수형 프로그래밍의 핵심 개념이 확실히 자리 잡힐 것입니다. 이 개념들은 도메인 주도 설계뿐만 아니라 모든 종류의 프로그래밍에도 유용합니다. (181쪽)

 

파이프라인의 각 단계부터 독립적인 함수로 구현합니다. 상태나 부수 효과가 없도록 함수를 구현하여 독립적으로 테스트하고 추론할 수 있게 해야 합니다. 그다음으로 이 작은 함수들을 모아 하나의 큰 함수로 합성합니다. 말은 쉬운데 실제로 해보면 디자인한 함수들의 출력과 그다음 함수의 입력이 서로 맞지 않는 문제와 맞닥뜨리기 일쑤입니다. 이런 문제를 해결하려면 함수들이 조합 가능하도록 각 단계의 입력과 출력을 조작하는 법을 배워야 합니다. (200쪽)

 

이 장에서는 도메인 모델을 어떻게 영속시킬지 설명합니다. 먼저 명령-질의 분리(command-query separation)와 같은 일반 원칙을 논의한 뒤 구현 디테일을 살펴봅시다. 특히, 도메인 모델을 NoSQL 문서형 데이터베이스와 전통적인 SQL 데이터베이스에 영속시키는 두 가지 구현 방식을 알아봅니다. 이 장을 마치면 영속화 메커니즘 연동에 필요한 모든 지식을 갖추게 될 것입니다. (323쪽)

김은민 (컨스택츠 CTO)

함수형 프로그래밍 개념은 좋은 코드를 작성하는 데 도움이 된다고 알려져 있습니다. 그래서 최근 프로그래밍 언어들은 대부분 함수형 프로그래밍 개념을 지원하며, 객체지향 언어를 사용하더라도 함수형 개념을 권장하는 분위기입니다. 함수형 프로그래밍을 사용하다 보면 도메인 주도 설계를 어떻게 적용할 수 있을지 고민하게 되지만, 관련 자료는 많지 않습니다. 이 책은 타입스크립트와 코틀린을 사용해 함수형 프로그래밍과 도메인 주도 설계를 연결하며, 특히 타입 시스템을 활용해 도메인 지식을 코드로 명확하게 표현하는 방법을 설명합니다. / 원서는 대중적이지 않은 F# 언어로 작성되어 실무에 적용하기 어려운 점이 있었습니다. 하지만 옮긴이가 타입스크립트와 코틀린으로 예제를 다시 작성해 많은 개발자가 쉽게 활용할 수 있게 되었습니다. 이러한 노력 덕분에 이 책은 큰 소장 가치가 있다고 생각합니다. / 더 나은 코드를 작성하고 싶은 모든 개발자에게 추천합니다.