分ける基準は「変わる理由」

第6回では役割で分けました。もう一段大きな単位、たとえばファイルのまとまりやサービスの境界を決めるときは、「それはなぜ変わるのか」で分けます。

変わる理由が違うものを1か所に混ぜると、デザインを直すたびに応募のルールまで触ることになります。

依存の向き：中心は外を知らない

「AがBを知っている（Bの名前や使い方を前提に書かれている）」ことを、AはBに依存していると言います。

向きの原則は1つです。業務ルールのような変わりにくい中心は、チャットツールやメール配信のような外側の道具を直接知らないようにします。中心は「通知する」とだけ言い、何で通知するかは外側に任せます。

応募のルール
   │ 「通知して」とだけ言う
   ▼
通知の窓口
   ├──▶ チャットツール
   └──▶ メール

こうしておくと、チャットツールを乗り換えても、応募のルールは1行も変わりません。

置き場所が寿命を決める

データや設定の置き場所も、設計の一部です。naminori の実例です。

• 講座のスライド画像は、サーバーのディスクではなくファイル保管用のサービスに置いている。サーバーを作り直してもスライドが消えないように
• サーバー上で直接変えた設定は、デプロイの仕組みでは元に戻らない。だから変えたものを一覧表に記録する決まりにしている。記録しないと、作り直した瞬間に消える

「これはどこに置いてあり、何をしたら消えるか」を言えることが、境界を決めるということです。

最初から細かく分けすぎない

境界は、引くほど連絡の手間が増えます。最初から小さなサービスに分割すると、1つの変更で何か所も直すことになりがちです。まずは1つのアプリの中で、役割と変わる理由で整理する。 本当に別々に変わることが分かってから、外に切り出します。

• 「変わる理由」で分ける
• 依存の向き：中心は外側の道具を知らない
• 置き場所が寿命を決める（naminori の実例）
• 最初から細かく分けすぎない