S_a_k_Uの日記みたいなDB

~サクゥーと呼ばないで~

UとIの続き

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