まとめ
- クリーンアーキテクチャーは、
- UIやツール、データの保存方法などを「変化が起きやすいもの」、ビジネスのコアなルール（ロジック）をそれと比べて「変化が起きにくいも」のとして住み分けをしている
- 変化が起きにくいものは、変化が起きやすいものに依存しないように、順番に並べて依存の方向を大事にしている
- 結果的にテストしやすく、新陳代謝もしやすい、柔軟なシステムが構築できる
Q&A
なんでこんなに何層ものレイヤーに分けるの？
- ロジックを関心によってグループ化することで下記のメリットがある
- 修正の目的や頻度もグループ化され、良くいじるところとそんなにいじらないところが分かれる
- (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フレームワークなど
- 逆に緑より内側ではフレームワークなどの影響を排除する
このレイヤー構造を徹底しないとだめなの？
- 飽くまでコンセプトを伝えるために書き出されたものなので、カスタマイズはOK
- 次の点は守りたい
- 依存方向は内側に向かって一方向
- 内側が抽象度が高く、外に行くにつれて具体的（詳細）になって行く