ドメイン駆動設計に啓発されながら、データ駆動設計の経験が長い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のオブジェクトリレーショナルマッパーだ。