Domain Modelという言葉の使い方に自身がないので、Model(Controller+Data)としてみるw
EntityはEntityで、またDBでのエンティティと紛らわしいので避けてみるw
今自分でセオリーとしている、現実のU字型アーキテクチャの基本思想(分析レベル?)はこんな感じ。
+--------+ +--------+ | ユーザ | | DBMS | +========+ +========+ | UI | |DTO/DAO | +--------+--------+--------+ | Model(Controller+Data) |←実装モデル(個別要件の実現) +--------------------------+ | Abstract Model |←抽象モデル(再利用アセット) +--------------------------+
実はこれに奥行があって、3次元でのレイヤ構造になる。
UIにも機能単位で依存関係があったり、Modelでも機能単位で依存関係があったりみたいな。
多分ここでの機能単位は一般的にはサブシステムだったり、ユースケースの単位だったりというようなイメージ。
奥行きには、世に言う「フレームワーク」や「コンポーネント」があったり。
またAbstract Modelには、それらを抽象化したものを包含してみたりする。
で、実際のプロジェクト(設計レベル?)ではこんな感じ。
+--------+ +--------+ | ユーザ | | DBMS | +========+ +========+ | UI | | DTO | +--------+-------------+ / | |Model(Controller+Data): DAO | +-------------------------------+ | Abstract Model | +-------------------------------+
ModelとDTO/DAOの境目を、パッケージ単位で切り分けして、依存関係を維持してる状態。
本来はFactoryをインターフェースとして定義して、それにModelが依存して、DTO/DAOはFactoryのインターフェースを実装するって感じだと思うけど、システムのライフサイクルやプロジェクトの状況などを踏まえ、アーキテクチャ上重要ではないという判断。
某プロジェクトでの、PL/SQLからJavaへのポーティティングでは、DBの構造に変更がない&Javaで実装する画面が少ないため、こんな感じにしてみたり。
ControllerでMapの値を参照して、ロジックを粛々と処理するだけ。
+---------------+ | ユーザ | +===============+ | UI | +---------------+ | Controller | + - - - - - - - + | java.util.Map | +---------------+ | DTO/DAO | +===============+ | DBMS | +---------------+
こんなのがあるかどうか判らんけど、(Z)と(Y)と(X)の領域の依存関係なんかが、しっかり維持できるかどうか(維持しやすいかどうか)で、この構造が堅牢かどうかみたいな話になって、通常見にくくなったり、依存関係ぐちゃぐちゃになってスパゲティ、とかって事態に陥りやすいということからアンチパターンになるんじゃないかと。
+--------+ | ユーザ | +========+ | UI | +--------+-----------------+ | (Z) | +---------------+ Domain | | DTO/DAO (Y)| | +========+--+---+ Model | | DBMS | |(X) | +--------+ +--------------+
重要なのは構造を明確にして、それに沿ったパッケージ/クラス設計が行われればよいと思ってる。
あとは、プロジェクトの環境やアーキテクトの好みかとw
多分アーキテクトの好みのウェイト高いと思うけどw