概要

ものすごい大ざっぱな人がクリーンアーキテクチャ勉強したのでその記録
本読んだだけなので間違ってたら指摘ください
本には書いてない自分の感想（そのように解釈したのも含む）は、章節項の頭に「（感想）」と書く
（感想）読書のモチベーション
- 昔からデスクトップアプリの開発が苦手
- 今はC#でもPrismとかあって非常に良い
- それでもしんどいのでこれさえ守っておけばオッケー的な定石を知りたい

（感想）自分の今の結論

超要約
- レイヤアプローチ
- 外側は直近の内側にのみ依存する
- 依存関係が逆にならないように「依存関係逆転の法則」を用いる
- 内側、外側に入る固有名詞は重要ではない（システムで違う）
- 何が内側で何が外側かを見極めるのは実は難しい
クリーンアーキテクチャとはメタアーキテクチャである
メタアーキテクチャはすべてのソフトウェアで同じである
クリーンアーキテクチャとは依存関係の話である

（感想）なぜ自分がメタアーキテクチャと呼んでいるのか

ユースケースが内側にくるのが一般的だが、何が内側で何が外側でも問題ない
一般的なアーキテクチャは構造について言及している
クリーンアーキテクチャは構造のルールについて言及している
良いアーキテクチャの構造を示すための定理が「原則（ルール）」

（感想）書籍は以下について書かれている

モジュール
- オブジェクト指向の原則
コンポーネント
- コンポーネントの原則
アーキテクチャ
境界
- バウンダリとも呼ぶ。どこでレイヤを分けるか？
クリーンアーキテクチャ（自分の言うメタアーキテクチャ）
クリーンアーキテクチャにおける設計の勘所と俗説の嘘（書籍の1/3）
ソフトウェアの歴史（書籍の1/4）
読むのが大変なのはコンポーネントのところまで（がんばろう）

内容

前ふり

ソフトウェアアーキテクチャの真理
- 「アーキテクチャの【ルール】はすべて同じである！」

モジュール

（感想）よく知られているので「依存関係逆転の法則」だけおさらい
オブジェクト指向の原則
- 単一責任の原則
- 開放閉鎖原則（Open-Closed Principle）
- リスコフの置換法則
- インターフェイス分離の法則
- 依存関係逆転の法則
依存関係逆転の法則
- レイヤの境界をまたがる矢印の向きが逆なのに注目

コンポーネント

（感想）コンポーネントの善し悪しの議論はされないことが案外多い
コンポーネントの原則
- よく知られていないので要理解
  - 再利用リリース等価の原則（REP）
  - 閉鎖性共通の原則（CCP）
  - 全利用の原則（CRP）
- 三すくみでトレードオフになっている
コンポーネント図の使い方
- （感想）クリーンアーキテクチャでは重要な図
- コンポーネント間の依存に問題がないか
- 循環依存の検出
- 循環依存があるとビルドできねえよ
  - （感想）某社で.NETのシステムで問題になっているのを聞いた
安定依存の法則
- 依存するなら安定した方に依存
- 外側から内側に依存するのがクリーンアーキテクチャなら内側が安定してないとダメ
安定度・抽象度等価の原則
- 抽象度が高いほど安定度が上がる
- 安定度の高い内側を改変する場合は「開放閉鎖原則」を使う
安定度と抽象度のマトリクス
- 物事には程度がある
- 抽象度が低く安定度が低すぎるとしんどい
- 安定度が高く抽象度が高すぎると無駄

アーキテクチャ

方針と詳細
- 方針＝アーキテクチャ、アーキテクチャは安定度の高い抽象レイヤに存在する
- 詳細＝実装、実装は安定度の低い具象レイヤに存在する
- フレームワークのような詳細の決定は遅延させる
独立性
- アーキテクチャがユースケースの意図を表現する
  - ショッピングカートのアーキテクチャはショッピングカートに見える
- アーキテクチャはシステムの振る舞いに影響しない

境界

（感想）何が内側で何が外側かという判断の難しい話につながる
いつ何に境界線を引くか？
- UIはビジネスルールにとって重要ではない（外側の存在）
- データベースも外側
- ビジネスルールは内側なので切り離す
- フレームワーク、ライブラリは外側なので後で決める
- 境界線は変更の軸のあるところに置く
データの受け渡し
- インターフェイス、データの定義は呼び出される側（つまり内側）にある

（まとめ）クリーンアーキテクチャ全体像

全体像

レイヤアプローチ
- 外側は直近の内側にのみ依存する
- 依存関係が逆にならないように「依存関係逆転の法則」を用いる
安定度と抽象化の話
- 抽象度が高いほど安定度が上がる
- 内側ほど抽象度が高いことになる
境界の話
- 標準的なレイヤの「あくまで例」
- UIとかWeb、RDBMS、デバイスはIOなので外側
- IOを抽象化、制御するレイヤがその内側
- ビジネスルールを制御するのがユースケースでその内側
- ビジネスルールをエンティティと呼び、最も内側

（感想）ちなみに

組み込み開発でも適用可能なアーキテクチャ
MVVMがクリーンアーキテクチャである例示
- クリーンアーキテクチャの例の図を参照
- ビューが一番外の青い部分
- ビューモデルとモデルが緑の部分（密結合が許される）
- サービスが赤い部分
- サービスから呼ぶビジネスロジックが黄色の部分
- モデルのうちRDBMSアクセスはORM（またはDAO）を介して青い部分に戻る
- 依存関係と抽象度、安定度を確認すること
- MVVMはクリーンアーキテクチャに含むことができる
- つまりMVVMとクリーンアーキテクチャはアーキテクチャのメタ度のレベルが違う
BCE、3階層アーキテクチャとの違い
- BCE
  - メロンを左に倒した図形が「バウンダリ（B）」
  - 再読み込みボタンみたいな図形が「コントロール（C）」
  - 丸の下に棒がある図形が「エンティティ（E）」
- 3階層アーキテクチャ
  - 非常に見慣れているので詳細割愛
- これらはレイヤアプローチだが、依存の方向の考え方が違う
- これらだとUI（BCEで言うバウンダリor3階層のプレゼンテーション層）が最上位になる
- 依存性の観点がないと古い人にはクリーンアーキテクチャは直感に反す
- 書籍の中ではBCEはクリーンアーキテクチャに含まれると言及
- 書籍の中では3階層はアーキテクチャでなくトポロジだと言及