レイヤ構成
http://d.hatena.ne.jp/aufheben/20050816
すごくコメント欄が伸びてる。。
以前の自分のエントリでもそうですが*1、レイヤの議論で組み込み系の人とビジネス系の人が入り乱れると面白いです。ビジネス系だけだと、どうも発想が固まってしまう部分がありますから。組み込み系は抽象度別レイヤを強く意識するし、ビジネス系はいわゆるプレゼン->ビジネスロジック->データソースといったレイヤに対する意識が強い気がします。
レイヤ分けは開発チームのスタイル、(開発)文化的な側面にも関係がありそうな気がします。ビジネス系では画面チームとかビジネスロジック要員といったチーム分けが多いので、それに合ったレイヤ構成が合理的になります。
でも実際に作り始めるとビジネスロジック要員が結構画面を意識して設計するハメになることが多いです。クラスの依存関係は問題ないけど、実際の作業レベルでは逆方向に依存してるじゃんというわけです。プレゼン層に向けたDTOを作成するための変換ロジックをBL側で面倒みる場面が多いからです。これって初期の志を忘れているというか意味無い気がします。その意味でGLAD!さんのエントリも面白いです。
プレゼン層でLazyLodingして表示するデータを必要に応じてフェッチするようにすれば、BL層はビジネスロジックの実行だけに集中できます*2。この場合OO設計的には美しくなりますが、発行されるSQLが制御しきません。もうキリが無いです。永続化FWのキャッシュ等が上手く働くのを期待するしか無いというか。
まぁマーティンたんが言うほど単純では無いということか。
変換ロジックを外だしして、このようなBLからプレゼンへの逆依存を無くすDxoが福音になるか否か? というところですかね。
以上とりとめない感じでした。つーか多次元レイヤ流行らんかなー、絶対議論がシンプルになると思うのに。。
(追記):
個人的な結論としては、アプリ固有層ではBLからプレゼンへの依存はあっても良し、ドメイン固有*3層ではダメといった形が良いと思ってます*4。さらに理想的にはアプリ固有層内での横方向(プレゼン<->BL)依存は全面禁止、それより下のドメイン固有層に対する依存を上手く使って通信するというイメージですかね。
