クリーンアーキテクチャーのQ&A #CleanArchitecture

まとめ

クリーンアーキテクチャーは、
- UIやツール、データの保存方法などを「変化が起きやすいもの」、ビジネスのコアなルール（ロジック）をそれと比べて「変化が起きにくいも」のとして住み分けをしている
- 変化が起きにくいものは、変化が起きやすいものに依存しないように、順番に並べて依存の方向を大事にしている
- 結果的にテストしやすく、新陳代謝もしやすい、柔軟なシステムが構築できる

ロジックを関心によってグループ化することで下記のメリットがある
- 修正の目的や頻度もグループ化され、良くいじるところとそんなにいじらないところが分かれる
  - (e.g.) UI層は更新頻度が高く、刷新機会も多い
- 良くいじられる層を外側にし、依存方向を内側向きの一方向にすることで、外側を捨てやすくなる
  - (e.g.) ReactをVueにする
  - (e.g.) 自前DBを外部APIにごっそり差し替える
- サービス（プロダクト）にとって大事な部分が中心に集まり、webでもアプリでもCUIでもヘッドレスでも使えるようになる
- その関心に着目したテストが描きやすくなる
  - (e.g.) UIを意識せずにユースケースをテストすることができる
  - (e.g.) ATMでもネットでも窓口でも関係なく、銀行では残高以上のお金を引き出せないテストができる
「not for ロジックの共通化や流用」、「for 保守性や変更容易性」
- 例え他で流用できない常に1:1のような分離でも、保守性や変更容易性が上がるのであれば分離する

黄：Enterprise Business Rules
- 一番のコアロジック
- ここが変わると全ての層に影響がある
- アプリケーションに依存しない
  - (e.g.) 会計ソフトは様々なものがあるが、それらの計算の元となる法律は一緒（法律がコア）
  - (e.g.) webでもアプリでもCUIでも共通のルール
赤：Application Business Rules
- アプリケーションに固有のルール
- アプリケーションが何をできるのかを書いていく
- 基本的にはコアロジックを順番に呼び、ユーザーのやりたいことを実現する形になる（ユースケース）
  - (e.g.) うちの会計ソフトは、この法律をこういう手順で処理していくよ
  - (e.g.) webユーザーは情報を一括で見せる、スマホアプリユーザーには少数精鋭で見せる
緑：Interface Adapters
- 青と赤の架け橋となり、データの変換を行う
  - (e.g.) DBが処理できるようにSQLに変換する
  - (e.g.) viewが使いやすいオブジェクト形式に変換する
青：Frameworks & Drivers
- DBやwebフレームワークなど
- 逆に緑より内側ではフレームワークなどの影響を排除する