iOSやAndroid開発ではCleanArchitectureというアーキテクチャが利用されることがあるが、利用者によって解釈が大きく変わりそれが自分の中での混乱を招いているのでは？と考えた。なので自分なりに整理してみた。
CAとDDDの混乱
CleanArchitectureは
- ヘキサゴナルアーキテクチャ
- オニオンアーキテクチャ
- スクリーミングアーキテクチャ
- リーンアーキテクチャ
- UseCase駆動
などのアーキテクチャを参考にしており、オニオン型アーキテクチャは
DDDのドメイン層からインフラ層への依存をなくすために依存性逆転の法則を用いて**「ドメインが何にも依存しないように」**する
という目的で生まれたものなので、DDDの文脈を受け継いでいると考えてよいと思った。
Entity/UseCaseの混乱
クリーンアーキテクチャ(The Clean Architecture翻訳)を読み直してみた。
Entityの定義の中の一文で以下のように書いてある。
エンティティは、メソッドを持ったオブジェクトかもしれない、あるいは、データ構造と関数の集合かもしれない。
そしてUseacaseはこのように書かれている。
ユースケースは、エンティティからの、あるいはエンティティーへのデータの流れを組み立てる。そして、エンティティ、プロジェクトレベルのビジネスルールを使って、ユースケースの目的を達成せよと指示する。
Entityはデータ構造だけでUseCaseにロジックを持たせるような利用がよくされているが、原文はちゃんとドメイン駆動の文脈に沿った使い方を想定されている。
なので、Entityにはドメインのロジックを持たせて、UseCaseはユーザーの利用する機能単位のロジックを設けてエンティティへのデータの流れを組み立て、インターフェース(抽象)に依存してお互いやりとりする。というのが正しいCAの理解ではないか？と考える。
この辺りのEntityとUseCaseの誤解が原因で、アプリケーションロジックとドメインロジックの混同が生まれてしまってドメイン駆動の旨味を損なってしまっていた気がする。
「テスト可能」の適応範囲の混乱
CAのシステムとして、
- フレームワーク独立
- テスト可能
- UI独立
- データベース独立
- 外部機能独立
が挙げられるが、2.テスト可能についての詳細は以下のようになる。
ビジネスルールは、UI、データベース、ウェブサーバー、その他外部の要素なしにテストできる。
このビジネスルールについて、前はUseCaseとEntityの混同があったために単にUseCaseに対してのテストだと考えていたが、CAの図では
Entities: Enterprise Business Rules
UseCases: Application Business Rules
と表現されており、UseCaseもEntityもビジネスルールで、どちらも外部の要素なしにテストされる という適応範囲の解釈の違いがあったように思う。
Interface Adapterの役割の混乱
このレイヤーはヘキサゴナルアーキテクチャーのAdapterに当たる。
CAでの定義は以下になる。
このレイヤーのソフトウェアは、アダプターの集合だ。これは、ユースケースとエンティティにもっとも便利な形式から、データベースやウェブのような外部の機能にもっとも便利な形式に、データを変換する。(中略...)
同じように、データはこのレイヤーで、エンティティーやユースケースにもっとも便利な形から、どんな永続化フレームワークが使われているにしろ、それにとってもっとも便利な形に変換される。
インターフェースアダプターに属するのは
- Controllers
- Gateways
- Presenters
なので、Viewや外部のDBでの内外のデータ形式変換はこいつらが行う。
UseCaseがデータ変換の責務を負ってはいけない。
しかし、データ変換の役割だけならTranslatorで問題ないわけなので「Presenter/Controller/Gatewayのそれぞれの役割を果たしつつ、内外のデータ変換の責務も負ってね。」という理解をしている。