アプリケーションは、ドメイン駆動設計 (DDD) を使って構築しなければならないと言われる。実際のドメインモデルは、エンティティか、DTOで構成される。DTOは、ビジネスと基盤となるロジックを組み合わせたものを含むサービスと共に、データとロジックを分離したものだ。コンサルタントとソフトウェアアーキテクトとしての経験を交えながら、Gabriel Schenker氏がこのように述べた。メッセージを扱うアプリケーションでは、ドメインからメッセージの名前を付けることはめったにない。代わりに、一般的な名前、例えば update や modify が使われる。
現在、主任ソフトウェアアーキテクトとして働いているSchenker氏は、これが古いアプリケーションにだけ当てはまるような誇張された話ではないと主張する。なぜなら、今まで初期の段階で、新しいアプリケーションを構築するプロジェクトを見てきたからだ。この主な理由の1つは、知識の不足だとSchenker氏は考えている。
DDDを扱う場合、 Eric Evan氏のオリジナルのDDD本に出てくるパターンが、すべて等しく重要なわけではないとSchenker氏は強調する。Evans氏が認めているように、DDDの基礎はその本の後半部分に書かれていること注意しよう。 これらの戦略的パターンとは逆に、前半部分は、 実装の詳細と限定的なパターンに注目している。
DDDを使って新しいプロジェクトを始める場合、ビジネスドメインを理解するために、最初にドメインの専門家と取り組むことを、Schenker氏はアドバイスする。ドメイン専門家との議論から、全員で同意した共通用語を作るために使われる専門用語を抜き出す。それを、DDD用語では、ユビキタス言語と言う。これに従い、別々にできる分野を識別するためにドメインの専門家を使い、サブドメインやその他の関係する内容、別のDDD用語を作ることで、複雑なドメインは細かく分けられる。
Schenker氏が警告したことの1つは、データモデルで始まる、データ中心の世界を作成することだ。Schenker氏は、分離されたデータは役に立たないと、強く信じている。データが意味のあるようになるにはロジックが必要だが、これは内容によって様々であることに、注意しよう。内容とロジックは、DDDの実施に第一に注目すべきだ。データに注目した場合、もう1つのリスクは、データベースが統合のために使われて終わってしまうことだ。コンテキスト間で依存を効果的に作り出す。そうでなければ、分離する。Stefan Tilkov氏によると、共通のデータモデルを使うことは避けたほうがよい。