
203
導
入
編
1
設
計
編
ア
キ
テ
ク
チ
ャ
編
2
3
4
5
6
7
4
ジックを入れないだけ、DomainModelをシンプルに保つことができます。
結局のところ、オブジェクト指向のカプセル化という考え方のメリットも
デメリットも踏まえたうえで、ビジネスロジックとデータをカプセル化する
のかが論点になると思います。多くの場合、データベースのテーブルに変更
があれば、ビジネスロジックにも影響が及ぶのが普通ですので、Domain
Modelにメリットがあるように思えます。ただ、DomainModelにもデメ
リットはあるので、TransactionScriptを採用した場合にカプセル化が行え
ない分のデメリットを他の設計手法で担保できればよいのです。このトレー
ドオフは、開発プロジェクトによって判断するしかないでしょう。
TransactionScript
と
DomainModel
この議論にはまだ結論は出ていないようです。ただ、非常に主観ですが、
やはりJavaで開発することが多い人には、TransactionScriptを支持する
傾向があるように思います。Java では、ビジネスロジックの細分化が非常
に進んでいます。個人的にはやり過ぎだと思うほどです。EJBやStruts、
DI などのJavaコミュニティが提供するさまざまなフレームワークの影響が
あるように思います。フレームワークを使ってシステムを開発すると、自
然とそのフレームワークが持つ設計思想のようなものを受け継いで設計し
てしまいます。それは良いことで、優秀な ...