クソコード動画「Userクラス」で考える技術的負債解消の観点
https://youtu.be/ajPaGPdj6tU?t=8916
技術的負債になりやすい筆頭Userクラス
風刺動画
なぜ負債になりやすいのか
まとめ
モデリングは、特定の問題解決のため、物事の特定の側面を抽象化（発表中の意味は「要約」）したもの
Userクラスはまともにモデリングされていないのが原因
現実世界の物理的存在とシステム内のモデルは1:Nの関係になる可能性がある
一貫性があり、疎結合高凝集な設計に役立つモデリングをするには、システム化対象の人の営みや、営みに伴う問題の理解が必須
問題の深い理解は、品質面だけでなく、より有益なモデル設計に繋がり、ビジネス価値向上を期待できる
動画で描かれた問題
個人も法人も同じUserクラス😱
1. 必要とするデータが状況によって異なる
個人に法人番号、法人に生年月日、それぞれ不要
2. 名前に「人名」「会社名」
ルール（制約）が異なる
3. いろんなクラスがUserクラスに依存
設計ミスに近い
ロジックを整理するだけのリファクタリングでは解決できない
負債解消に必要な観点を共有
Userクラスの抱える問題
関心事の異なる問題を1つのUserクラスで扱ってしまっている
特定の問題解決を意図した構造になっていない
複数の問題解決にUserクラスを利用
利用者のあらゆる側面を意味しているように見えてしまう
どうとでも解釈可能
（ミノ駆動本では「ガバガバ」）
個人と法人では解決したい問題が違う
ミクロなシステムとしては異なる
法人番号と生年月日
必要となる情報が違うのに一緒くた
あらゆる側面→巨大クラス化
密結合
Userクラスは全然モデリングされていない
種類の異なる問題がシステム内に複数存在することを認識できていない
個別の解決システムとして分離されているべきだが、まとめられてしまっている
（ミノ駆動本では「一貫性がない」）
この資料で一番伝えたいこと
現実世界の利用者とシステム内のモデルは1:1になるとは限らない
1:Nになる可能性がある
たった1つのモデルに統一せず、関心事に応じたモデルをそれぞれ設計する
ミノ駆動本、出版予告