EJB3時代のアーキテクチャパターン
EJB3時代のアーキテクチャパターン
結構OO厨と呼ばれがちな僕なんですけど、プレゼンモデルとドメインモデルは分離していいと思う。役割が違うなら当然*1 。ただCustomerに対して全く同じ内容のCustomerDTOを対応させるような、重複してるプレゼンモデルはあんまし意味無いなーとは思う。
個人的にはプレゼンモデルをどのような単位で切るかが興味ある。「現在のアーキテクチャ」ならページ毎になると思うんだけど、近い将来、GWTみたいなツールキットを使った場合にどのような粒度に切るべきか? おそらくユーザインタラクションに対して何らかの分割可能な単位を考える必要があると思う。
あとプレゼンモデル自体を永続化したい場合、どう裁けばいいのかも気になっている。真のリッチなユーザ体験は、システムがユーザのことを覚えてくれる事から始まると思う。近年のリッチクライアントフレームワークでは、組み込みのDBにその手の情報を保持するものがあるみたい。(追記:なんか伝わりづらいこと書いてしまったかも。システムにドメインが複数あり、ユーザインタラクションドメインとビジネスドメインがあるという話です。)
ビジネス層に関しては、個人的にDomainModel=Entity*2という考え方自体がイマイチ納得いかない。PofEAA等では力説されてるけど。まずテーブルに対応するEntity自体には大したロジックを持たせられない。一番の問題はグローバルサーチ*3をEntityが行うのに抵抗ある点。柔軟性がゼロになってしまうし、はっきり言って複雑すぎる*4。OO厨にも限界あるよ。
かといってグローバルサーチが出来なければビジネスロジックを実装するなんて無理。この手の問題はORマッパーでは解決できない。コマンドとかサービスのような状態を持たないオブジェクトにビジネスロジックをすべて実装することにすれば一応シンプルに解決できるように見える。しかし今度はサービスが状態判定とコンテキスト情報引渡しの塊になり、前世紀のプログラム化してしまうのでイマイチ。
振る舞いも状態も持つリッチなDomainObjectが、薄いEntityとかルールオブジェクトを掴んでアレコレするみたいな仕組みがいいんじゃないかなーと思う。SCAなんかはこんな感じなんじゃなかろうか。DDDではAggregateがそれにあたるのかな*5。S2Buriにおけるワークステートもちょっと違う観点かもしれないけど、問題意識は一緒だと思う。まだDomainObjectが複数の関心に対応しなきゃならない問題が残っているけど、これに関しては、Separation of Concerns系の技術的なソリューションがありそう。
うーん専門家の意見が聞きたい。
追記:この記事でひがさんが意識しているようなベタなOO厨って日本には少なそう*6。欧米には多そう。適当なイメージなんですが。
