ドメインエキスパートとやりとりをしない、というのが、ドメイン駆動設計 (DDD)でよくある失敗のひとつであり、これを早い段階で修正することで、チームの時間を節約できると、Daniel Whittaker氏は説明する。氏は、DDDの実践の中で、よく出くわす10の失敗についての説明の中で、この点を指摘した。
永続化やデータストレージがモデルに影響を与えてしまう、というのも失敗のひとつだ。戦略的パターン、例えば、アグリゲートのルートは、モデルをシンプルにし、データストレージのようなインフラから分離する。ドメインエキスパートと話す代わりに、スキーマやデータモデリングから始めてしまうと、コードはドメインモデルではなく、リレーショナルモデルをベースにしたものになってしまう。同じような問題をStefan Tilkov氏が以前に指摘していた。氏は、標準的なデータモデルをエンタープライズの世界で使うことについて警告した。モデルが選択的な属性や奇妙な振る舞いを持つようになってしまうからだ。
ドメインエキスパートと交わらない、というのも失敗のひとつだ。ドメインエキスパートと話し、彼らの視点から問題領域を理解することは、DDDの中核だ。振る舞い駆動開発(BDD)はドメインエキスパートとの会話を強調し、振る舞いのサンプルを作る。Konstantin Kudryashov氏は以前、BDDとDDDの実践を合わせることについて話していた。
ドメインエキスパートの言葉を無視する。ドメインエキスパートと共通のユビキタス言語を作ることは、DDDの実践の中核のひとつだ。共通語はすべての議論とコードで使われなければならない。
境界付けられたコンテキストを特定しないのも誤ちのひとつ。複雑な問題を解決する共通の方法は、その問題を小さな問題に分割することだ。境界付けられたコンテキストは、大きなドメインを小さなドメインに分割する。それぞれの小さなドメインは全体のドメインの密結合した一部として扱われる。マイクロサービスにとっても重要な概念であり、Eric Evans氏は今年のDDD Exchange conferenceの基調講演で、この話をした。
ドメインモデル貧血症に陥ってしまうことも失敗と言えるだろう。これは、チームがDDDを実践できていないことを示す兆候のひとつとして一般的であり、モデリングプロセスの失敗を表している。まず、ドメインモデル貧血症は、一見すると、正しい名前を持つ本物のドメインモデルのように見える。しかし、クラスにはほとんど振る舞いがなく、プロパティのゲッターとセッターしかない。
Whittaker氏がよく見る、10のDDDの失敗のうち、残りの5つは、以下の通りだ。
Whittaker氏が言及する、最後の誤ちはイベントストーミングを考慮しない、ということだ。イベントストーミングとは、イベントに着目した設計手法で、Alberto Brandolini氏が考案した。主要な利害関係者をひとつの部屋に集め、制限のないモデリングスペースを使い、付箋をドメインイベントに見立ててモデリングをすることで、数時間で良いモデルが作成できる、とBrandolini氏は主張する。