BT

データ駆動開発からドメイン駆動開発へ

| 作者: Jan Stenberg フォローする 33 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2013年10月23日. 推定読書時間: 2 分 |

原文(投稿日:2013/10/16)へのリンク

ドメイン駆動設計に啓発されながら、データ駆動設計の経験が長いJulie Lerman氏は自身のスキルをDDDで活用する方法を理解するのに苦労をしてきた。2003年よりMicrosoft MVPである氏はコンサルタント、メンターとして活動している。氏は多くの開発者が自身と同様の経験をしていると考え、自身が学んだことをMSDN Magazineの3つ記事に書いている。

DDDは複雑な振る舞いのための設計であり、アプリケーションのすべてのパーツがそのような複雑な振る舞いの中に収まるわけではない、というのが氏の考えだ。単純な作成、読み取り、更新、削除(CRUD)は、DDDでないやり方が実装に適しているが、複雑な振る舞いとCRUDの組み合わせの場合、複雑な部分を特定し、コンテキスト境界で分割してDDDを適用するのが良い、という。

DDDを実践してドメインを設計するときは、ビジネスにフォーカスして、必要なタスクと振る舞いをモデリングする。データの永続化はビジネスとは無関係であり、それゆえ、ドメインの設計の邪魔をしない、補助的な役割になるべきだ。

氏が問題に感じたトピックのひとつは、型とデータをサブシステム間で共有することについてだ。氏の考えでは、型を共有するのは必須だった。しかし、DDDによれば、ドメインモデルを共有するのは必須ではなく、違うサブシステムから同じ型のデータを別のテーブルやデータベースに保存することも問題ない。データが重複するのは犯罪ではないのだ。長期的にみれば、データの共有を排除することでシステムは単純になる。

また、ORMを使ったときの問題についても触れている。氏の場合はEntity Frameworkだ。問題のひとつは一方向の関連についてだ。DDDでは一方向の関連は望ましいとされている。DDD本の著者であるEric Evans氏によれば、“関連を可能な限り厳格にすることは重要”だ。しかし、双方向の関連はEntity Frameworkを使っている氏にとって、必然的なものであった。双方向は便利であるものの、実際のドメインで必要になることはまれで、双方向を排除すると関連を管理する上での複雑さを排除できるというのが、氏の得た教訓だ。

氏の記事にはC#とEntity Frameworkを使ったサンプルコードがついている。Entity FrameworkはMicrosoftのオブジェクトリレーショナルマッパーだ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT