이미 소장하고 있다면 판매해 보세요.
|
옮긴이 머리말 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)’는 법칙이 적용됩니다. 불분명한 요구사항이나 잘못된 디자인과 같은 옳지 않은 입력으로는 어떤 코드도 원하는 결과를 생성해내지 못합니다.
--- p.3 도메인 모델을 소프트웨어로 어떻게 구현할지 훑어보기엔 적기입니다. 빠른 개발 사이클에서는 종종 도메인 전체를 파악하기도 전에 일부를 먼저 구현해야 하는 경우가 생기기도 합니다. 따라서 구성 요소들을 모두 만들기 전에 이들을 어떻게 결합해야 할지 고민해야 합니다. 전체 시스템이 어떻게 동작할지 보여주는 엉성한 프로토타입, ‘워킹 스켈레톤(walking skeleton)’을 만드는 것에 대해서도 할 얘기가 많습니다. 일찍이 무엇을 어떻게 구현할지 살펴보는 것은 아직 충분히 이해하지 못한 부분을 찾아내는 최선의 방법입니다. --- p.45 지금까지 도메인을 올바르게 모델링하기 위한 노력을 해왔다면, 이제는 도메인의 모든 데이터가 유효하고 일관되도록 몇 가지 예방 조치가 필요합니다. 신뢰할 수 없는 외부 세계와 구분하여 경계 진 맥락 내에서는 신뢰하는 데이터만 있게 할 것입니다. 맥락 내 모든 데이터가 항상 유효하다고 확신할 수 있다면 깔끔한 구현은 물론, 불필요한 방어 코드를 피할 수 있습니다. --- p.121 지금까지 주문 처리 작업 흐름에 대한 요구사항을 파악하고 타입으로 모델링했습니다. 이제 그 디자인을 함수형 프로그래밍 방식으로 구현하는 것이 다음 과제입니다. / 본격적으로 들어가기에 앞서 함수형 프로그래밍이 무엇인지, 그리고 구현을 위해 필요한 도구와 전략을 이해하는 것이 중요합니다. 이 장을 마치면 함수형 프로그래밍의 핵심 개념이 확실히 자리 잡힐 것입니다. 이 개념들은 도메인 주도 설계뿐만 아니라 모든 종류의 프로그래밍에도 유용합니다. --- p.181 파이프라인의 각 단계부터 독립적인 함수로 구현합니다. 상태나 부수 효과가 없도록 함수를 구현하여 독립적으로 테스트하고 추론할 수 있게 해야 합니다. 그다음으로 이 작은 함수들을 모아 하나의 큰 함수로 합성합니다. 말은 쉬운데 실제로 해보면 디자인한 함수들의 출력과 그다음 함수의 입력이 서로 맞지 않는 문제와 맞닥뜨리기 일쑤입니다. 이런 문제를 해결하려면 함수들이 조합 가능하도록 각 단계의 입력과 출력을 조작하는 법을 배워야 합니다. --- p.200 이 장에서는 도메인 모델을 어떻게 영속시킬지 설명합니다. 먼저 명령-질의 분리(command-query separation)와 같은 일반 원칙을 논의한 뒤 구현 디테일을 살펴봅시다. 특히, 도메인 모델을 NoSQL 문서형 데이터베이스와 전통적인 SQL 데이터베이스에 영속시키는 두 가지 구현 방식을 알아봅니다. 이 장을 마치면 영속화 메커니즘 연동에 필요한 모든 지식을 갖추게 될 것입니다. --- p.323 |
|
● 도메인을 제대로 이해하는 법
● 함수형 사고로 DDD 다시 보기 ● 타입으로 설계하는 모델링 기법 ● 파이프라인으로 표현하는 비즈니스 로직 ● 컴파일 타임에 오류를 차단하는 설계 ● 데이터베이스와의 유연한 연동 ● 코드와 문서가 하나가 되는 도메인 모델링 |
|
함수형 프로그래밍 개념은 좋은 코드를 작성하는 데 도움이 된다고 알려져 있습니다. 그래서 최근 프로그래밍 언어들은 대부분 함수형 프로그래밍 개념을 지원하며, 객체지향 언어를 사용하더라도 함수형 개념을 권장하는 분위기입니다. 함수형 프로그래밍을 사용하다 보면 도메인 주도 설계를 어떻게 적용할 수 있을지 고민하게 되지만, 관련 자료는 많지 않습니다. 이 책은 타입스크립트와 코틀린을 사용해 함수형 프로그래밍과 도메인 주도 설계를 연결하며, 특히 타입 시스템을 활용해 도메인 지식을 코드로 명확하게 표현하는 방법을 설명합니다. / 원서는 대중적이지 않은 F# 언어로 작성되어 실무에 적용하기 어려운 점이 있었습니다. 하지만 옮긴이가 타입스크립트와 코틀린으로 예제를 다시 작성해 많은 개발자가 쉽게 활용할 수 있게 되었습니다. 이러한 노력 덕분에 이 책은 큰 소장 가치가 있다고 생각합니다. / 더 나은 코드를 작성하고 싶은 모든 개발자에게 추천합니다. - 김은민 (컨스택츠 CTO)
|