InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
神様ルートクラスを嫌い、POJOを好む：An Agile Way：オルタナティブ・ブログ
ぼくがオブジェクト指向言語を勉強しはじめた90年ころは、「継承」という概念がとても流行っていて、継承によって「差分プログラミング」ができることがオブジェクト指向設計の再利用性の典型例のように言われていた。もちろん、こういう誤解は95年くらいには、みんなウソだと分かってきていた。 しかし、それでもときどき、 すべてのクラスの頂点のような「神様クラス」を作ってしまうことがある。 例えば、90年代の多くのC++オブジェクト指向データベースは、Persistenceのようなクラスを継承することで永続オブジェクトとなるクラスをマーキングしたり、あるベンダーのコレションクラスは、Objectというクラスを継承したクラスのオブジェクトのみがコレクションの要素となることができたり、という具合に。また、EJBも最近まではEntityBeanを継承することでEntityBeanの資格が得られるし、Servel
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
