Clean ArchitectureにおけるEntityとModel

Clean Architectureで書いているとEntityやModel（InputData/OuputData）について悩むことがあります。

• Entityにはどこまでビジネスロジックを書かないといけないのか？

• フィールドとアクセッサだけのEntityはだめなのか？

• Modelを使わず、EntityをController/UseCase/Presenterで共有したらだめなのだろうか？

人の数だけ答えが分かれそうですし、自分の考えも変遷していきそうです。

色々調べて、最終的には「手を動かしてわかるクリーンアーキテクチャ」という本を読んである程度、納得できたので今の自分の答えを整理してまとめます。

Entity

• Entityは必要
  • Clean Architectureはドメイン層（Entity）を守るための構造
  • Entityという本丸がなければ意味がない
• Entityの中身はユースケース次第
  • ビジネスロジックが多い/濃いユースケースならEntityはDDDのEntityに近くなる
  • ビジネスロジックがあまりないユースケースならEntityはフィールドとアクセッサだけのPOJOになる
  • Read-onlyなユースケースの場合はただのDTOになる
• ドメインレベルのInput ValidationはEntityの役割
  • 薄いEntityの場合はUseCaseが実装する
• UseCaseとの分解点もユースケース次第
  • ビジネスロジックが濃い場合、UseCaseは入力を検証し、EntityやGatewayを呼び出すだけ
  • ビジネスロジックが薄い場合は、UseCaseがビジネスロジックをある程度、持つ

Model（InputData/OutputData）

• InputData/OutputDataはEntityとは別にあった方がよい
  • Controller、Presenter、UseCase、Gatewayが皆、Entityを使った場合、Single Responsibility Principleに違反する
  • ControllerやGatewayが使うモデルにはWEBフレームワークやDB固有のAnnotation等がついている可能性がある
• しかしシンプルなCRUDしか実施しないユースケースの場合は各層でデータが同じになるので、モデル変換の重要性が薄れコスパが悪くなる
  • 最初はCRUDのみのシンプルなユースケースが時間が立つにつれて発展していくこともある点には注意が必要
• 以下のような棲み分けになる
  • controller -> usecase -> presenter
    • 基本はEntityとModelを分ける
    • CRUDのみで、かつ将来的に拡張される可能性が低ければModelを使わず、Entityを共有するのも可
  • usecase -> gateway
    • 基本、CRUD処理なのでModelはなくてもよい
• アプリケーションレベルのInput ValidationはInputDataで実施
• 名前はXxxCommand、XxxRequest、XxxOrder、XxxResponse、XxxDTOなどとする
• Modelは他UseCaseと共有しない
  • 他のUseCaseの影響を受ける
• Modelは原則、Controller側に置かない
  • UseCaseを守る境界の一部なのでUseCase InterfaceやPresenter Interfaceと同列の場所に置く