この章で伝えたいこと
第2章・第3章では、構造を共通化しすぎた結果として起きる歪みや、モノリスが生まれる過程を見てきました。 本章では一段視点を上げ、「良い構造」を直接目指すのではなく、良い判断が積み重なった結果として構造が決まる という考え方を扱います。
設計が破綻する現場では、多くの場合「判断」がコードの外に散らばり、後から追えなくなっています。 その結果、なぜこの構造になっているのか、どこまで壊してよいのかが分からなくなります。
本章のゴールは、
- 構造よりも判断に目を向ける
- 判断をコードに閉じ込める
- 将来の変更に耐えられる思考の軸を持つ
この3点を理解することです。
構造は「結果」であり「目的」ではない
設計の話になると、
- レイヤードにするか
- モジュールをどう切るか
- どこを共通化するか
といった 構造そのもの に議論が集中しがちです。
しかし実際には、構造はその時点での判断の積み重ねの結果にすぎません。
- なぜこの責務をここに置いたのか
- なぜこのクラスに依存させたのか
- なぜこの抽象を導入したのか
これらの判断が変われば、同じ要件でも構造はまったく別の形になります。
構造だけを真似しても、判断の前提が共有されていなければ、すぐに歪みが生まれます。
判断が失われると、構造は硬直する
モノリス化したコードベースでよく見られるのが、
- このクラスを触っていいのか分からない
- どこまで変更してよいのか判断できない
- とりあえず既存の流れに合わせる
という状態です。
これは「構造が悪い」以前に、 なぜその構造になったのかという判断が失われている ことが原因です。
判断の背景が見えない構造は、
- 壊すのが怖い
- 変更が最小限になる
- 例外処理が積み重なる
結果として、さらに判断不能な構造へと進化していきます。
良い設計は「線を引く」行為である
設計とは、突き詰めると 線を引く行為 です。
- どこからどこまでがこの責務か
- ここから先は別の判断に委ねる
- このユースケースでは扱わない
線を引くということは、同時に「やらないこと」を決めることでもあります。
線が引かれていない設計では、
- 責務が広がり続ける
- 境界を越えた依存が増える
- 修正の影響範囲が読めなくなる
という問題が必ず起きます。
判断をコードに残すという発想
判断は、ドキュメントや頭の中に置いておくと必ず失われます。
そこで重要になるのが、 判断をコードの形で残す という考え方です。
- 型で制約する
- sealed class で分岐を限定する
- インターフェースで責務を分ける
これらはすべて、 「こういう使われ方は想定していない」という判断をコードに刻む行為です。
判断がコードに残っていれば、
- 間違った使い方はコンパイル時に弾かれる
- 新しい要件が来たときに、線を引き直す場所が分かる
構造は自然と壊れにくくなります。
まとめ
- 構造は設計の目的ではなく、判断の結果である
- 判断が失われると、構造は硬直し、モノリス化する
- 設計とは線を引き、責務と境界を明確にする行為である
- 判断はコードに残して初めて、将来に耐えられる
次章では、こうした「判断」をどのように分解し、チームで共有していくかを扱います。