アプリの設計

アプリの設計

執筆済 ソフトウェア開発設計

どこで分けるかを決めること。

分けかたの軸#

軸 例
技術的な層 UI / ビジネスロジック / データ
機能 認証 / 検索 / 決済
変更の理由 一緒に変わるものをまとめる

3 番目が本質的。 Conway の法則や単一責任原則が示すのは、 同時に変わるものを同じ場所に置くという指針。

凝集度と結合度#

望ましい状態
凝集度 高い。1 つのモジュールが 1 つのことをする
結合度 低い。モジュール間の依存が少ない

依存を減らすと、片方を変えても他が壊れない。 依存性注入や クリーンアーキテクチャは 依存の向きを制御する手段。

過剰設計を避ける#

層を増やせば柔軟になるが、 読むべきファイルも増える。

小さなアプリに 5 層 → 1 つの機能追加に 5 ファイル触る

YAGNI（今必要ないものは作らない）が有効なのは、 将来の要求はたいてい予想と違うから。 予想して作った拡張点は使われず、 予想しなかった場所を変えることになる。

判断の目安#

状況 適する構造
個人・小規模 層を薄く。素直に書く
中規模・複数人 機能単位のモジュール化
大規模・長期 明示的な層、依存の逆転

規模と寿命に合わせるのが要点で、 絶対的に正しい構造は無い。

参考文献#