設計 / アーキテクチャ
変更しやすさを構造で買う
設計の良し悪しは「動くかどうか」では測れない。測れるのは、仕様変更が来たときに何ファイル触るか。凝集度・結合度・依存の向きは、その「触る範囲」を制御するための語彙であり、SOLID もレイヤードもその適用例にすぎない。
読み終わると、これに答えられるようになります
- ?依存性逆転は具体的に何を逆転させているのか
- ?レイヤードアーキテクチャで DB のカラム名が画面まで漏れるのはなぜ問題なのか
- ?「共通化」がかえって変更を重くするのはどういうときか
基礎14分
凝集度と結合度 — 変更したとき何ファイル触るか
良い設計は「動くか」では測れない。測れるのは、仕様変更が来たときの影響範囲。それを制御する2つの語彙。
「共通化」したユーティリティに分岐が増え続け、1箇所の修正が3画面を壊した
応用15分
SOLID — 5つの原則が守ろうとしている1つのこと
暗記する対象ではなく、判断の道具として使う。それぞれが「どういう変更に備えているか」から理解する。
決済手段を1つ追加するのに、既存の分岐を12箇所書き換えることになった
応用15分
レイヤードアーキテクチャ — 依存の向きを一方向に揃える
層に分けること自体に価値はない。価値があるのは、依存が一方向であることと、業務ロジックが技術から独立すること。
DB のカラム名を変えたら、画面のテンプレートが壊れた
発展16分
ドメインモデリング — 業務の言葉をコードの形にする
テーブル設計から始めると、業務ルールの置き場所がなくなる。何が概念で、何が制約かを見つける作業。
金額を number で持ち回り、税込と税抜が混ざった状態で合計されていた