「ドメイン駆動設計をはじめよう」を読んだ感想
9sako6公式サイトからわかる情報以上の内容には言及していないつもりで個人的な感想を連ねる。
1章 事業活動を分析する
エンジニアの仕事は課題解決だから、事業領域について知らないといけないよね。
ただ、事業に話の重点を置くとすれば、競合優位性を生み出す中核の業務領域が必ずしもソフトウェアで実現される必要はないんだよな。（余談）DOORDASH というフードデリバリーのスタートアップは最初創業者自身がデリバリーしていたらしい。[1]
事業領域はいくつかの業務領域に分類される。
どの業務領域が利益をもたらすものなのか、見極めるのが大事だが難しい。
9sako62章 業務知識を発見する
業務エキスパートと同じ言葉（ユビキタス言語）をつかって事業領域の細部を知ろう。
意図の伝達は大事。伝言ゲームはやめよう。
仕事をしていると、同じ言葉の解釈が人によってずれてると感じることがたまにある。
「プロセスやツールよりも個人と対話」を。
日本語の同じ言葉を使おうと思っても、コード上では英語で表現する必要があるので命名のマッピングはいつも頭を悩ませるよな。
9sako63章 事業活動の複雑さに立ち向かう
同じ言葉にしても、区切られた文脈によって区別されるよ。
例えばチームが少人数で事業規模も小さいが、区切られた文脈が存在しそうな場合、マイクロサービスに切り分けたほうがいいんだろうか。ある程度大きなモデルを許容してモノリスにするのがいいんだろうか。
これが我々エンジニアの設計の腕の見せ所となるね。
この辺は 8 章、10 章でも話がありそう。
区切られた文脈と業務領域を一対一に対応させることが最善の場合もあるでしょうし、別の方針で分割することが役にたつ場合もあるでしょう。
9sako64章 区切られた文脈どうしの連係
Consumer-Producer の従属関係には馴染みがある。
この場合、CDCテスト (Consumer Driven Contract Test) で契約を結ぶよね。
9sako65章 単純な業務ロジックを実装する
PofEAA で読んだことあるトランザクションスクリプト。
私は運用作業とか分析用データ出力とかにトランザクションスクリプトを使っている。
9sako66章 複雑な業務ロジックに立ち向かう
ドメインモデルの実装の話だが、理解し切ったかあやしい。
値オブジェクトでバリデーションしたり業務ロジックのカプセル化ができる。
そして実装上の工夫としてはイミュータブルであるべき。このやりやすさは言語によっても変わるかな。Rust だと実装者が必ず気にする必要があるので良い。
そこでマーチン・ファウラーはimmutableにすべき(should)であると言っている。
9sako67章 時間軸でモデルを作る
イベントソーシングの話。事業領域に即したユビキタス言語のイベントを使って実装できる点で DDD と相性がいいのかもしれない。
一方で、イベントを保存してビジネス的価値がないならオーバーエンジニアリングだね。
本書ではイベントソーシングではなく「イベント履歴式ドメインモデル」という訳になっており、イベントソーシングよりは狭く、ドメインモデルの集約の状態管理にイベントソーシングを使っているという意味合い。
インフラも色々選ぶが、個人的には決済周り実装するときはお世話になったイベントソーシング。
決済みたいな、ほぼ一般的な業務領域だったらあんまりないけど、頻繁に変更が予想される中核の業務領域でイベントの破壊的変更なんてのは大変そうすぎてつらい。
9sako68章 技術方式
9sako69章 通信
9sako610章 設計の経験則
9sako611章 設計を進化させる
9sako612章 イベントストーミング
9sako613章 現実世界のドメイン駆動設計
9sako614章 マイクロサービス
9sako615章 イベント駆動型アーキテクチャ
9sako616章 データメッシュ
9sako6結びの言葉
9sako6