- 根源にある考え方
- 一度に考慮すべき範囲は小さいほど上手くいく
- KISS原則
- その考え方に基づくアプリケーションの構築方針
- 小さく区切られたブラックボックスを組み合わせて大きいシステムを造る
- divide-and-conquer/分割統治
- link
- 良い分割の方針
- 何に基づいて分割するか
- 関心ベース: 関心の分離 −利点とそれを促すアーキテクチャ−
- 何に基づいて分割するか
- 分離面 (インターフェース) の形式 (∝質)
- 分割された要素間の関係性
分離面 (=インターフェース) の質
モノリスをぶった切ればひとまずインターフェースは生まれる
これを変更（改良・修正）する際のコストが1つの指標。
他には関心の分離を促進してくれるか崩しやすいか
変更に対するコスト
変更不可、はありえない。実務上変更困難、はよくある
良いインターフェースは内部変更コストを小さくしてくれて、動的なコードを可能にする
インターフェースの種類: 呼ぶ & 公開して呼ばれる (プライマリー & セカンダリーアダプター in ヘキサゴナルアーキテクチャ)
変更しづらい形式とは
変更がインターフェースそのものの変更を起こしてしまうパターン.
インターフェースが内部実装と強く関連しており、内部実装の変更や差し替えに大規模なコード変更を必要とする場合.
目的とインターフェースが不一致（不必要に広い、必要以上に絞られている）と起きやすい
e.g. "保存"が目的なのに、DynamoDBに対するpostが目的となっているインターフェース
インターフェース形式はその設計にownershipを持つ関心事から強く影響を受ける
外部サービスが当然APIを持っているので、そこを出発点として抽象化していきがち
良いインターフェースを書くコツ
私のためのインタフェース、は私が
依存したいインタフェースは、依存する人がよくわかってる
インタフェース設定の手間をかける価値があるドメインなら、依存するインタフェースを自分でownership取って設計する
- 自分で決めるから閉じた開発が可能
- 良質なインターフェースが実現
「抽象への依存」そのものが大切なのか？
Q: 低レベル具象クラスの構造をインターフェースとして切り離し、それをDIでドメインモデルに渡したらクリーンアーキテクチャなのか？
A: No。使いづらいインターフェースだったらさっぱり目的 (実質的依存の軽減からくる柔軟性とテスタビリティ) を達成してくれない。インターフェースへの依存そのものが重要なわけではない。ドメインモデル中心/主導のインターフェース設計が肝。
Q: 神が設計した、最高の一般化がなされた具象クラスがあったとして、これに直接依存したコードを書くことに問題はあるか？
A: No. 具象クラス内部の実装変更が影響しないように一般化済みなので、高い柔軟性やテスタビリティは確保されている。
これらのことから、「良い分離面」設計が肝心であることがわかる。
「抽象への依存」は良い設計を実現する手法だった？
アーキテクチャフレームワークがもつ役割
理想と乖離しやすい部分を解決
内向き依存のみにする、と言う指針は、コアドメインに対しinterfaceのownershipを強制する効果がある
