Tackling Complexity
kawasima
設計ナイト 2022

ドメインモデルは「複雑さ」に対応するものである
複雑
シンプル
Theorem
ファウラーのあやまち
ドメインモデルパターンを「An object model of the domain that
incorporates both behavior and data」って定義しちゃっているため、オブ
ジェクト指向パラダイムに縛られている。

では「複雑さ」とは何なのか?
Simple Made Easy
https://github.com/tallesl/Rich-Hickey-fanclub

シンプルの反対の意味である「複雑」とは…?
1つの塊に複数のものが混在している状態
● 複数の役割
● 複数のタスク
● 複数の概念
● 複数の次元
構造の複雑さ
(凝集度に関連)

「複雑」は別の意味で用いられることもある
パーツの数が多く、それらが関連していること
NetflixのMicroservices構成

2種類の「複雑さ」
構造の複雑さ
● 分解可能
○ 分解するとパーツが増え、関
係性の複雑さが増す
● 凝集度の話
○ データにもfunctionにも存在す
る
関係性の複雑さ
● 業務を変えない限りは、不可避
● サブドメイン分割など、分割統治で
立ち向かう
● 構造の複雑さと解消しないと、見え
にくい
Out of the tar pit だと
Accidental Complexity Essential Complexity

Kent BeckのSimple Design
1. 全てのテストがパスする (Passes the tests)
2. 意図が明確である (Reveals intention)
3. 重複がない (No duplication)
4. 最小の構成要素 (Fewest elements)
https://martinfowler.com/bliki/BeckDesignRules.html
これは「関係性の複雑さ」についての言及
今必要ないものを作り込んで、設計要素を増やすな (YAGNI)

ドメインモデルというからには
構造の「複雑さ」を解消してなくてはならない

00年代によく見られたドメイン層の実装

実態として、構造の複雑さが解消されていない

「あちこちで料金計算していたロジックを、料金の
クラスにまとめました。」
＼＼高凝集／／ ＼＼ドメインモデル／／
ってなりかねない…
ドメインモデリングでは「構造の複雑さ」をどう減らすか、
もっとフォーカスされなくてはならない
＼＼脱トランザクションスクリプト／／

構造の「複雑さ」を別のレイヤ
に押し込めることじゃなく
https://github.com/kawasima/kata

構造の複雑さをシンプルに

渡辺幸三さんの「データモデリング入門」より
ここでは「複雑さ」に構造と関係性両方を含んで
の話だが、上の図は構造の複雑さを含んだ
データモデルは、処理系の構造も複雑にしてし
まう、ことを表している
データとプロセスの複雑さの関係

Wrap up
● 「複雑さ」は2種類あるので、分けて考えよう
● 「構造の複雑さ」はSimple Made Easy - wayで分解する
● 「関係性の複雑さ」は「構造の複雑さ」を解消しないと見えにくい
● 「複雑さ」に対処するのが、ドメインロジックのパターンの本質
○ なんだけど、パターンそのものは、構造の複雑さ解消の土台を作っているだけに過ぎない
○ 地道に構造の複雑さを解消していかない限りは「複雑さ」が移動しているだけになる

参考文献
● Scott Wlaschin “”Reinventing the Transaction Script
● Scott Wlaschin “Domain Modeling Made Functional”
● Rich Hickey “Simple Made Easy”
● 渡辺幸三 “データモデリング入門”
● Eric Normand “Grokking Simplicity”
● kawasima “https://scrapbox.io/kawasima/ドメインモデル貧血症”
● kawasima “https://scrapbox.io/kawasima/イミュータブルデータモデル”