コピペコードで快適生活

明日使えるソースを自分のために

クリーンアーキテクチャについて学んだことメモ

全体を通した感想

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

  • 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を分割

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

ControllerとUseCaseInteraction

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

PresenterとUseCaseInteraction

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

ViewModelとView

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

参考