Clean Architecture 読書メモ
アーキテクチャの価値とは
保守、拡張にかかるコストの少なさ
メンバーが増えているのに、機能拡張のペースが上がらない、まして下がっていたらコストが上がっている
設計の原則
これらはすべて拡張しやすくするためのもの
依存関係の逆転
インターフェイスを用いて依存関係を逆転する
コンポーネント設計
基本的にはSOLID原則を単位を大きくして当てはめる
依存関係を意識しながらacyclicになるようにする
循環参照になると変更の依存が増える
安定度と抽象度
安定度が低く、抽象度が高い: 無駄
安定度が高く、抽象度が低い: 辛い
DBがそれ。変更されることが多いのに、影響範囲が大きい。
Util コンポーネントはこれになりがちだが、そもそもの変更頻度がすくない
Java の String など
第3軸として、変更頻度を置いて考える
理想エリアに収まっていないコンポーネントを発見し対処する
アーキテクチャ
詳細の決定を遅らせる
詳細とは
I/O
UI, REST, Web
データストア
DB => Cache
Repository として抽象化し、DIPを apply して依存を逆転させる
データストアがビジネスロジックに依存するようにする
境界をどのように引くか
vs DRY(Dont Repeat Yourself)
偶然の重複、なら重複して良い。拡張の自由度が増す。
vs YAGNI(You Ain't Gonna Need It)
マイクロサービス
本質的な依存関係は緩やかに残る
データ構造、データストアの構造
ゆえに、デプロイにも調整が必要になる