アーキテクチャがごちゃごちゃにならないようにするにはどうしたらいいかは常に考えているが、 元々ごちゃごちゃになった後に参加したところは手遅れ感があるし、ゼロから超慎重に考えたつもりでもごちゃごちゃしてきてしまう
このごちゃごちゃを「大きな泥団子」と例えて、どう立ち向かうべきかの設計指針を話されている増田さんのスライドが面白かった
面白いと思ったのは、自分が最近読んで感銘を受けたDMMFやGrokking Simplicityの本の話とリンクするところがあるところで、実践してみたいなーと思っていたことを増田さんに後押ししてもらったような感覚になった
スライドに書かれていた「大きな泥団子」の要因には本当に共感した
- 積み上がるバックログ
- 無理な日程
- 度重なる仕様変更
- 限られたリソース
- 人の入れ替わり
- ビジネスの圧力
私もいくつかプロジェクトを経験してきて、もう綺麗に整理整頓されたプロジェクトなんて不可能なのでは？と考えてすらいたりする
この泥団子にどう立ち向かうか
大きな泥団子とは要するに「関心の分離の失敗例」であるという
数々ある設計技法の、根底の設計原則は「関心の分離」が目的であるが、これができていない
なので、ちゃんと関心の分離しようという話
どうやってやるかというと、処理を以下の３つの枠組みに切り分ける
- 計算
- アクション
- アダプター
計算とは
算術演算や比較演算、条件分岐、コレクション操作など、実行タイミングや実行回数に依存しない処理のこと
これに切り分けるメリットは３つ
- 計算の複雑さを分離できれば、他が単純になる
- 品質保証（テスト）を重点的に実施できる
- 業務を正しく深く理解して実装できるようになる
このあたりがGrokking Simplicityの本にも書かれていたことでもあり、すでに試し始めていたことであるが、2はモックもスタブもいらないので本当にテストがしやすくなる
本当の意味のユニットテストが行えている感覚がある
計算の分離の設計技法としては以下の２つが挙げられる
- 抽象データ型をつくる
- イミュータブルにする
この抽象データ型は、値の種類を特定し、正しく分類しなければならないので「経験則」と「習熟」と「共創」が特に必要だなと感じる
事業活動の理解と観測が重要である
アクション
スライドでは業務機能とあるので抽象度の高い機能のことを言っているのか、少し理解しきれなかったが、Grokking Simplicityの本では「計算」とは逆に、呼び出した時と回数がシステムに影響するもの（副作用があるもの）と定義されている
例えば、メール送信やファイル操作など
確かにビジネスの独自性や競合優位性に結びつくものではない
アダプタ
スライドではアクションの呼び出し元で、フレームワークや設計パターンに依存するもの
INアダプターとOUTアダプターがあるとされている
まとめ
テクニックはよくわかるとして、スライドにも本にもあるが、重要なのは分離した関心について会話することで、エンジニアが進めるにしてもレビューなしではうまくいかない気がする
ステークホルダーと会話できる雰囲気も合わせて大事かなと思った
