レイヤ構成

id:aufheben:20050816 の続き。

昨日のひがさんの発表を聴きながらこんな 絵 を描いてみました。

レイヤ間の依存関係は、
プレゼンテーション層 --> ドメイン層 --> データソース層
で上位レイヤが下位レイヤに依存しています。
モデルすなわちデータはレイヤの境界に位置し、上位/下位両方のレイヤから使用されます。各層のインタフェースは実装する側に置いたけれど、境界または使用する側に置くこともできます(使用する側に置くと依存関係が逆転する)。

その上で、前回の問題意識を整理してみます。EoD (= Ease of Development) を考えると、ドメインモデルはデータ仕様書(テーブル仕様書)、プレゼンテーションモデル(この名称はもう少し考えた方がいいかも)は画面仕様書から自動生成するのが簡単。でも、そうするとビジネスロジックが画面仕様、データ仕様に依存してしまう。画面仕様やデータ仕様に依存するということは、具体的な製品には依存しないけれどアーキテクチャには多少なりとも依存してしまう。と、まぁこういうことです。
それで、何が問題かというと特に問題はないと思います(前回も別にそれがダメだとは言っていないはず)。「再利用性」を考えると気持ち悪い気がしないでもないですが、ビジネスロジックだけ取り出して再利用なんてありえないし、平鍋さんの「EoM=EoC+EoT」はちゃんと実現できます。