第2章では、 判断がどのようにシステムを壊していくのかを見てきた。

この章では、いよいよ本題に入る。

では、判断をどのように扱えばよいのか。

答えはシンプルだ。 判断を、閉じ込める。

ただしこれは、 単にロジックを隠すという話ではない。 設計として意味のある「閉じ込め方」には、 いくつかの技術と考え方がある。

「閉じ込める」とは、どういうことか

判断を閉じ込めるとは、 その判断に責任を持つ場所を決めることだ。

  • この判断は、どこで行うのか
  • どこから触ってよいのか
  • どこからは触ってはいけないのか

これを曖昧にしたまま設計すると、 判断は必ず広がる。

逆に言えば、 閉じ込めるとは 判断の影響範囲を限定する行為 に他ならない。

強く閉じる、弱く閉じる

すべての判断を、 同じ強さで閉じ込める必要はない。

判断には、それぞれ性質がある。

  • 外れたら致命的な判断
  • 外れてもすぐに直せる判断
  • プロダクト全体に影響する判断
  • 画面単位で完結する判断

重要なのは、 判断の重さに応じて、閉じ込め方を変えること だ。

強く閉じるとは、 型や境界によって、 簡単には触れないようにすること。

弱く閉じるとは、 変更を前提に、 差し替えやすい形で置いておくこと。

設計とは、 この強弱を意識的に選び続ける行為だ。

境界は、判断のために存在する

レイヤやモジュールの境界は、 整理のためにあるのではない。

そこには必ず、

「この判断は、ここまで」

という線が引かれている。

境界をまたいで判断が漏れ出すと、 設計は一気に脆くなる。

  • 上位レイヤが下位の事情を知りすぎる
  • 本来関係のない変更が波及する
  • 境界を守る意味が失われる

境界とは、 判断を隔離するための装置 だと捉えたほうがよい。

型は、判断を固定する道具である

型は、 安全性のためだけに存在するのではない。

型は、

「この判断は、こういう形でしか存在しない」

と宣言するための道具でもある。

型を使うことで、

  • 許される状態
  • 許されない状態

を設計者が先に決めることができる。

これは、 判断をコード全体ににじませないための、 非常に強力な手段だ。

抽象化は、判断を動かす余地を残す

抽象化は、 判断を消す行為ではない。

判断を あとから差し替えられる場所に押し込める 行為だ。

良い抽象化は、

  • 何が変わりうるか
  • 何は変わらないか

を、はっきり分けている。

逆に言えば、 何が変わるか分かっていない状態での抽象化は、 判断を拡散させる原因になる。

共通化は「閉じ込め」ではない

共通化は、 しばしば閉じ込める行為だと誤解される。

しかし実際には、 共通化は 判断を集める行為 だ。

  • 同じように見える処理
  • 今は似ている振る舞い

これらを一箇所にまとめることで、 判断のスコープは広がる。

だからこそ、 共通化は慎重に扱わなければならない。

閉じ込める前に共通化すると、 判断は逃げ場を失い、 システム全体を縛り始める。

判断を閉じ込められている状態とは

判断がうまく閉じ込められているとき、 コードには次のような特徴が現れる。

  • 変更点が、ほぼ一箇所に収まる
  • 修正理由を説明できる
  • 壊すときに、壊す場所が分かる

これは、 設計が「うまくいっている」サインだ。

完璧である必要はない。

判断の置き場所を、自覚できているかどうか が、 設計者としての分かれ目になる。

まとめ

  • 閉じ込めるとは、判断の影響範囲を限定すること
  • 判断の重さによって、閉じ込め方を変える
  • 境界・型・抽象は、すべて判断のための道具
  • 共通化は、閉じ込めではなく拡張である

次章では、 これらの考え方を使って、 間違える前提で設計する とはどういうことかを掘り下げていく。