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

2023-04-02

概要

↑を読んだメモ

サンプルコードをRustに置き換えて遊んでたリポジトリは以下

Domain Modeling Made Functional の読書メモシリーズはこちら

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を表す

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

"C4" approach

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

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

"bounede context"をコード上でどう扱うか

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

"bounede context" 間でのデータ転送

"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 1, Chapter 1~3)

2023-04-02