全体を通した感想

たぶんこういうことかなと。

UIとビジネスルールとDBを疎結合とすること
- 変更容易性の向上
  - 変更による影響範囲を小さくする
- テスト容易性の向上
  - テスト対象が依存するオブジェクトをモックに差し替えやすい

レイヤードアーキテクチャ

依存関係
- UI(Presentation) -> Application -> Domain -> Infrastructure
  - Domain: ビジネスルールを扱う
  - Infrastructure: 技術的詳細(DBへのアクセスなど)を扱う
安定依存の原則に反している
- 安定しているDomain層が、安定していないInfrastracture層に依存する状態になっている。
感想
- ビジネスルールとInfrastracture(=DB)が強く紐付いているのであれば、両方とも同じくらい安定していると考えることもできる。
- その場合は、安定依存の原則に反しているとは言えない。

依存関係を変える
- Domain -> DataAccessInterface(を備えたDataAccess) <- Database
  - Domainが依存するのはDataAccessInterfaceを備えたモジュールにだけ。
  - Domainに影響を与えずに、Database以外へのデータソースへの差し替えが可能になる。
https://bliki-ja.github.io/pofeaa/Repository/

Domain層は2つの役割を持っている
- ビジネスルール
- データ操作
問題点
- 互いの修正が影響を与えてしまいがち
- たとえば、価格の取得が product.price から product.product_pricing.price に変更になった場合、 price を扱うビジネスルールの処理を書き換える必要が出てくるかもしれない。
UseCaseInteractor -> Entities
- UseCaseInteractor: DataAccessを使ったデータの操作とEntitiesを使ったビジネスルール処理の実行を行う
- Entities: ビジネスルール処理を行う
感想
- Entitiesに記述する処理は、RailsのActiveRecordのインスタンスメソッドと対応してそう。
- UseCaseInteractorに記述する処理は、RailsのActiveRecordのクラスメソッドに書く処理と重なることが多そう。
- Entitiesにあるgetter,setterは多くの場合、テーブルのレコードと対応することになりそう。
  - カラムが増えるたびに、getter,setterを実装する手間がかかりそう。
  - RailsのActiveRecordは、UseCaseInteractor,Entities,DataAccessの役割を包括することで、getter,setterを自動生成し、実装する手間を削減していると思われる。

Controllerは、parameterの受け取りと、その値に応じたUseCaseInteractorを呼び出しを行う。
ControllerはUseCaseInteractorの振る舞い(InputBoundary)に依存する
- UseCaseInteractorの修正による影響をControllerに与えない
- UseCaseInteractorの交換を容易にする。
  - Controllerのtestでは、UseCaseInteractorモックを与えることで、容易性や迅速性の向上が見込める。
InputDataは、InputBoundaryに与えるデータの型
感想
- 主な機能はこの辺かな
  - parameterの値チェック
  - parameterの値に応じた条件分岐
    - UseCaseInteractorの呼び出しやエラーハンドリングなど

Presenterは、UseCaseInteractorからデータを取得し、表示用に加工してViewに引き渡す。
感想
- 表示に至るまでのステップは以下の人漆器
  - parameter受け取り → データ取得 → データ加工 → viewへの引き渡しになるので、
- なので、Controllerとは不可分ではないか

ViewModel は View のためのデータ構造体。
View は ViewModel をレンダリングする。
感想
- ViewはViewModelの写像という位置づけになりそう。
- ViewModelはEntitiesとかなり内容が重複しそう。
  - Railsでmodelを直接viewで使えるのは、重複排除が狙いかもしれない。