クリーンアーキテクチャ
いつもの図
https://cdn-ak.f.st-hatena.com/images/fotolife/a/ad-sho-loko/20190708/20190708031020.png
#オニオンアーキテクチャ では Frameworks & Drivers を Core と呼び、すべてのレイヤーから依存される存在としている クリーンアーキテクチャでは framework に依存するなとの主張だが、オニオンアーキテクチャでは依存すると言っている
Frameworks & Drivers のレイヤーには DB や Web サーバの実装、main 関数などが属する
ライブラリのコードを指す場合が大半？
自分では main 関数に相当するもの以外はほとんど書かない
/icons/hr.icon
ソフトウェアをレイヤーに分けることで関心を分離することが大きな目標
依存ルール
円の外から内側に向かってのみ依存することができる
これに違反してはいけない
インターフェースに依存することでこれを実現する
Dependency injection
エンティティ
外側の何が変わっても変わらなさそうなもの
ユースケース
エンティティを使って目的を達成する
エンティティを使ったデータの流れを組み立てる
インターフェースアダプター
エンティティやユースケースと具体的な外部のものを接続するためのもの
データを相互変換する
フレームワークとドライバー
外部 API や DB などの詳細
GitHub にあるサンプルコードを読んでいく記事
ユースケース層でドメイン層の整合性を担保する？
Go で簡単なアプリケーションを実装している
DDD との関係も書いてある
各用語の簡潔な解説表があって助かる
ユースケースはアプリケーションが何をできるのかを表現する
インターフェースのみで実装は持たない
gRPC みたいな感じでリクエスト/レスポンスが定義されている
Data Transfer Object (DTO)
この実装を Interactor と呼ぶ
図の色的にこいつも UseCases のレイヤーに置かれる？
Repository のインターフェースはこの例では Domain の中に定義されていた
ので、レイヤーとしては Enterprise Business Rule
実装は一つ外の Interface Adapter
Controller はユーザの入力を解釈し、UseCase に伝える
ユーザの入力を UseCase の理解できる形式に変換するので Interface Adapter のレイヤーにある
UseCase のインターフェースに依存する
DIContainer
どのインターフェースにどの実装を渡すかを設定するツール
Bus パターン
ユースケースが増えると Interface Adapter から依存するユースケースのインターフェースがたくさんになって面倒
これを解決するパターン
ルーティングぽい感じ
欠点としてアプリケーションが大きくなるとビジネスロジックレイヤーが肥え太る
これを解決するためのユースケースとドメイン知識の分離
アプリケーションの仕様をユースケース図とルール/制約で整理する
ユースケース
ユーザーとソフトウェアの間の相互関係を起こすアクション
"このソフトウェアの"ユースケースであり、アプリケーションがなければ存在しない
ドメイン知識
ソフトウェア化する対象領域に存在するルール
ソフトウェアがなくても、現実世界に存在する
ドメイン知識は現実世界における知識
紙にも書けるし、手でも運用できる
例と図が豊富でわかりやすい