この記事は
Clean Architecture 達人に学ぶソフトウェアの構造と設計
を初学者が読んでわかったことを書いているので、詳しく知りたい人には参考になりません。
クリーンアーキテクチャ
図1
以上の図は、以下を単一で実行可能なアイデアを統合したもの。
- フレームワーク非依存（機能満載のソフウェアはライブラリに依存しない。だから、システムはフレームワークで縛らず、ツールとして使用）
- テスト可能（ビジネスルールは、UIやデータベースなどがなくてもテストできる）
- UI非依存(UIはシステムの他の部分を変更しなくても、簡単に変更できる）
- データベース非依存（DBの置き換えが可能。ビジネスルールはデータベースに束縛されていない）
- 外部エージェント非依存(ビジネスルールは、外界のインターフェイスについても何も知らない）
依存性のルール
図１は、円の中央に近づくほどソフトウェアのレベルが上がっていく。
円の外側が仕組み。内側は方針。
クリーンアーキテクチャを動作させる最も重要なルールは、依存性のルールである
「ソースコードの依存性は、内側だけに向かっていなければいけない」
である
エンティティ
企業全体の最重要ビジネスルールをカプセル化したもの。
最も一般的で、最上位レベルのルールをカプセル化したもの。
外部が変化しても変わる可能性は低い。
ユースケース
アプリケーション固有のビジネスルールが含まれている。
システムの全てのユースケースがカプセル化・実装されている。
入出力するデータの流れを調整し、ユースケースの目標を達成できるように、エンティティに最重要なビジネスルールを使用するように指令する。
インターフェイスアダプター
ユースケースやエンティティに便利のファーマットから、データベースやウェブなどの外部エージェントに便利なフォーマットにデータを変換するアダプター。
フレームワークとドライバ
フレームワークやツールなど。
図にないものは、、、？
図にのっていないものでも問題はない。
だが、依存性のルールは常に適用される。
内側から外側を呼ぶには？
ユースケースからプレゼンターを呼び出す必要がある場合で考える。
依存性のルールに違反するので、直接は呼べない。
プレゼンターが、ユースケース出力インターフェイスを実装。
そのインターフェイスを使うと、ユースケース→プレゼンターを作れる。
境界線を超えるデータの形は？
依存性を持たせないように、独立した単純なデータ構造であることが重要。
内側が外側のデータを形式を知ると依存性のルールに違反するため、内側の円にとって便利の形式にする。