DDDの読書記録（第4章、ドメインを隔離する） - 達人プログラマーを目指して
DDDのモデル駆動設計では、在庫管理、注文管理といったドメインから生じる問題を解決するのに特化した部分に焦点を当てます。そして、ドメインの問題を他の問題から明確に切り離すことを設計上の至上命令としています。 これは夜空に星座を見つけ出そうとするようなものだ。ドメインオブジェクトはシステムの他の機能から切り離す必要がある。そうすることで、ドメインの概念を、ソフトウェアの技術にしか関係しない概念と混同したり、システム全体の中に紛れ込んでドメインを見失ってしまったりすることを避けられるようになる。 夜空に星座を見つけ出すというのも印象的な表現ですが、プラネタリウムで一見バラバラに並んでいる星の中からサソリや白鳥の形が線や星座絵によって浮き上がってくるように、ドメインモデルを探し出してはっきりとチーム全体でイメージを共有できるようにするということが重要だと思います。この章ではそのための前提となるレ
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
DDDがよく分かんないときに見てそこそこ分かった資料置き場 - DRYな備忘録
