業務システムと DDD の相性ってどうなんだろう - アジャイルプログラマの日常
技術に詳しいお客さんに「DDD って実際どうなの？」と聞かれた時、その有効性をどう説明すればいいかいつも悩んでしまいます。 個人的に思う一番のメリットは、テストをしやすいコードを書くことになるということです。 TDD (BDD) で開発しながら DDD に近づけるという手法をとった場合、コードのメンテナンス性が非常に向上する (だから、楽しい → DDD が好きになる) と感じています。 DDD Sample Application Naked Objects for .NET - 生産性の高い.NETフレームワーク The DDD Parcel Service WIKI - The DDD Sample Application Wiki 実際、業務システムと DDD の相性ってどうなんでしょうか。 どなたか、 DDD の業務サンプル (特に、対象領域が DB 付きの業務システムのオープン
デブサミ2010 - 出張！DDD難民救済キャンプで話してきました
DDD読書会＠JavaEE勉強会代表として、「DDD難民に捧ぐ」の佐藤さん、読書会主催syの角田さん、思想系プログラマの和智さん、モデレータのt-wadaさんと一緒にパネルをさせていただきました。 推進派の佐藤さん、懐疑派の角田さん、受託開発現場の立場から自分、言葉を重視する立場から和智さんと、短い時間ながら立場を明確にしたパネルができたと思っています。 【19-B-5】出張！DDD難民救済キャンプ View more presentations from kentaro714. パネルの内容自体に関しては、SlideShareをながめながらtsudaってくれた方のTweet（#devsumi2010ハッシュタグ）を眺めれば、おおよその話は見えてくると思います。特に@yattom さんがとても詳細にtsudaってくださっています。 # yattomさんありがとうございます！ というわけで、
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
