読書メモ：Domain Modeling Made Functional (Part 2, Chapter 4~7)


## 概要

[https://www.amazon.co.jp/dp/B07B44BPFB](https://www.amazon.co.jp/dp/B07B44BPFB)

↑を読んだメモ

サンプルコードをRustに置き換えて遊んでたリポジトリは以下
[https://github.com/homura10059/DomainModelingMadeFunctional_in_Rust](https://github.com/homura10059/DomainModelingMadeFunctional_in_Rust)

Domain Modeling Made Functional の読書メモシリーズ は [こちら](../series/bd9f5f797461f1f04bd00051b6f878d6)

## Part 1 Understanding the Domain

### Chapter 1 Introducing Domain-Driven Design

- shared mental model を作ることが DDD の中心 
- Domain を見つけるためには Event Storming をやってみるといい
	- 関係者と Event Storming をやってみると "私たち" vs "彼ら" という対立思考を避けられる
- Scenario
	- ユーザーが目的を達成するために求めているもの
	- アジャイルでいうstoryに近い
	- usecase はそれを詳細にしたもの（インタラクションの一つとか）
- Business Process
	- ビジネス(1ユーザーではなく大きい単位)が目的を達成するために求めているもの
	- ユーザー目線ではなくビジネス目線のSenario
- Workflow
	- Business Processの一部
	- 従業員やシステムが実行するstepをリストにしたもの
	- Business Process は Workflow のリストに分けられる
* *command* (DDD用語)
	* OOPのCommandパターンとは関係ない
	* domain event を発生させるもととなるリクエスト
	* Workflowを開始する
		* Woekflowが実行された結果としてEventが生まれることも多い
* `問題あるDomainは小さいsubdomainsに分割する`
	* 困難は分割せよ
* bounded contexts
	* 現実世界のドメインをドメインモデルに落とし込むときに作られたもの
	* 実装の中でいうサブシステム
	* 現実世界のドメインと bounded contexts が一対一対応する場合ばかりではない
		* 複数に分かれることもあるし、複数のドメインをまとめて一つになることもある
* 最も重要な Counded Contextsを見つける
	* core domain はビジネス的に重要なもの(金を稼げるもの)
	* それ以外は supportive domain や generic domain
* ユビキタス言語を作る
	* ドメインエキスパートと同じ言葉でmodelを表す

### Chapter 2 Understanding the Domain

- 具体をどう設計していくかという例が主
- database-driven や class-driven と比較しながらDDDの利点を説明
- class-driven の説明で FooBase みたいな基底作るけどこれは何も現実を表せてないだろみたいなこと言われててちょっと笑った
	- ネイティブでもFooBaseみたいな命名するんだ
	- なんの現実も表せてなくて抽象化できてない共通化はあるある


### Chapter3 A Functional Architecture

"C4" approach
- "system context"
	- システム全体のトップレベルを表す表現
- "containers"
	- "system context"はこれを複数含む
	- deployableな単位(web siteだったりweb serviceだったり)
- "components"
	- "container" は複数のこれで構成される
	- コードの中の主な構造物
- "classes"
	- "component" は複数のこれで構成される
	- 関数型アーキテクチャだと"modules"とも呼ばれる
	- 低レベルのメソッドや関数

変更コストを最小にするを目指す

"bounede context"をコード上でどう扱うか
- モノリスなら "component" として分ける
- マイクロサービスなら "container" として分けるとか

最初はモノリスにしておいて必要が出てきたら分けるのをお勧めする

"bounede context" 間でのデータ転送
* 境界ではDTOに詰め替える
* input gate
	* 信頼のおける "bounede context" の中では validation 必要ない
	* しかし外からやってくるデータには必要
* output gate
	* 外に出すデータには必要のないデータがleakしないようにする

"bounede context" 間の契約
- Shared Kernel
	- 複数の "bounede context" に共通した部分を、共通モジュールにするパターン
- Customer/Supplier or Consumer Driven Contract
	- downstream側の Consumer が必要な情報を定義する(契約として)
	- upstream側はその形式を提供する
- Conformist
	- upstream側が力を持っているなどの場合で、契約を定義せずそのまま使うパターン

Anti-Corruption Layers
- 外部システムがドメインモデルと合わない場合などに設ける

読書メモ

読書メモ：Domain Modeling Made Functional (Part 2, Chapter 4~7)

読書メモ：Domain Modeling Made Functional (Part 1, Chapter 1~3)