도메인 주도 설계를 위한 함수형 프로그래밍

옮긴이 머리말 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)'는 법칙이 적용됩니다. 불분명한 요구사항이나 잘못된 디자인과 같은 옳지 않은 입력으로는 어떤 코드도 원하는 결과를 생성해내지 못합니다.

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