設計ナイト2022 「トランザクションスクリプト」でのディスカッション枠スライドです。

What's hot

More from Yoshitaka Kawashima

Tackling Complexity

• 1.
  Tackling Complexitykawasima設計ナイト 2022
• 2.
  ドメインモデルは「複雑さ」に対応するものである複雑シンプルTheoremファウラーのあやまち

ドメインモデルパターンを「An object modelof the domain thatincorporates both behavior and data」って定義しちゃっているため、オブジェクト指向パラダイムに縛られている。
• 3.
  では「複雑さ」とは何なのか?Simple Made Easyhttps://github.com/tallesl/Rich-Hickey-fanclub
• 4.
  シンプルの反対の意味である「複雑」とは…?1つの塊に複数のものが混在している状態● 複数の役割● 複数のタスク●複数の概念● 複数の次元構造の複雑さ(凝集度に関連)
• 5.
  「複雑」は別の意味で用いられることもあるパーツの数が多く、それらが関連していることNetflixのMicroservices構成
• 6.
  2種類の「複雑さ」構造の複雑さ● 分解可能○ 分解するとパーツが増え、関係性の複雑さが増す●凝集度の話○ データにもfunctionにも存在する関係性の複雑さ● 業務を変えない限りは、不可避● サブドメイン分割など、分割統治で立ち向かう● 構造の複雑さと解消しないと、見えにくいOut of the tar pit だとAccidental Complexity Essential Complexity
• 7.
  Kent BeckのSimple Design1.全てのテストがパスする (Passes the tests)2. 意図が明確である (Reveals intention)3. 重複がない (No duplication)4. 最小の構成要素 (Fewest elements)https://martinfowler.com/bliki/BeckDesignRules.htmlこれは「関係性の複雑さ」についての言及今必要ないものを作り込んで、設計要素を増やすな (YAGNI)
• 8.
  ドメインモデルというからには構造の「複雑さ」を解消してなくてはならない
• 9.
  00年代によく見られたドメイン層の実装
• 10.
  実態として、構造の複雑さが解消されていない
• 11.
  「あちこちで料金計算していたロジックを、料金のクラスにまとめました。」＼＼高凝集／／ ＼＼ドメインモデル／／ってなりかねない…ドメインモデリングでは「構造の複雑さ」をどう減らすか、もっとフォーカスされなくてはならない＼＼脱トランザクションスクリプト／／
• 12.
  構造の「複雑さ」を別のレイヤに押し込めることじゃなくhttps://github.com/kawasima/kata
• 13.
  構造の複雑さをシンプルに
• 14.
  渡辺幸三さんの「データモデリング入門」よりここでは「複雑さ」に構造と関係性両方を含んでの話だが、上の図は構造の複雑さを含んだデータモデルは、処理系の構造も複雑にしてしまう、ことを表している
データとプロセスの複雑さの関係
• 15.
  Wrap up● 「複雑さ」は2種類あるので、分けて考えよう●「構造の複雑さ」はSimple Made Easy - wayで分解する● 「関係性の複雑さ」は「構造の複雑さ」を解消しないと見えにくい● 「複雑さ」に対処するのが、ドメインロジックのパターンの本質○ なんだけど、パターンそのものは、構造の複雑さ解消の土台を作っているだけに過ぎない○ 地道に構造の複雑さを解消していかない限りは「複雑さ」が移動しているだけになる
• 16.
  参考文献● 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/イミュータブルデータモデル”