yojikのlog

yojikのブログです

2次元レイヤについてもう少し考えてみた。

そういえば自分もDDD難民でした。。RDD難民でもあります。

2次元レイヤについてもう少し考えてみた。
まず縦軸横軸をひっくり返してみた。データソース層の横棒ないのは,のだめ風。あと兎角誤解を生むドメインという言葉を慎重に取り除いてみた。

        
              UCごと   業務共通  インフラ(FW)
---------------------------------------------
プレゼン層 |         |          |          |
---------------------------------------------
ロジック層 |         |          |          |
---------------------------------------------
デタソス層 |         |          |          |
---------------------------------------------

んでもて整理。

  • UCごとのプレゼン層
    • 説明不要
  • UCごとのロジック層
  • UCごとのデータソース
    • 微妙だがQueryは意外にUC固有のものであることが多い。SQLCommandパターン
  • 業務共通のプレゼン層
    • ちょい微妙。必要になることはある。共通で使うDTOとか?
  • 業務共通のロジック層
    • PofEAAのドメインモデル
  • 業務共通のデータソース層

(UC毎/業務共通)ロジック層のオブジェクトが,ステートレス、ステートフルのどちらであるべきか? これに関しては考えがまとまっていないので後回しにする。
インフラに関しての区分は,単純に左隣の区分に合わせた形。(これから外れるものもでてくるでしょう)。依存関係は左から右,上から下を基本とする*1
これらの枠から微妙とよばれるものを削除して,インフラ層を統合したりすると山野さんの紹介してたリンク先のものに近づいていく。真ん中の業務共通ロジックを重視すると,PofEAAで述べられている意味でのドメインモデルを中心とした形に近づく。
全枠フルで利用する機会は少ないのだろう(多分)
別件として,そもそも縦軸(前回は横軸)の分け方は本当にそれでよいの?という疑問も残る。例えばUC毎の軸は、名前の通りUCごとに細分化されると思うが、その単位が意外に難しそう。*2

*1:データマッパ利用時のデータソースとロジックなど依存関係が逆転場所もあるはず

*2:多分Goh氏の指摘はそのあたりについて述べているのだと思う