ドメイン駆動設計（DDD）とは何ですか？
DDD（Domain Driven Design）が記事で頻繁に使用されているのを見続けています-DDDに関するWikipediaのエントリを読みましたが、それが実際に何であり、サイトの作成でそれをどのように実装するかを理解できませんか？
まず、あなたがそれを必要とすることを知らないなら、あなたはそれを必要としない可能性があります。 DDDが解決する問題を認識しない場合は、おそらくそれらの問題はありません。 DDDの支持者でさえ、DDDは大規模（6か月以上）のプロジェクトのみを対象としていることを頻繁に指摘します。
この時点でまだ読んでいると仮定すると、DDDに対する私の見解は次のとおりです。
DDDとは、ソフトウェアを実際のシステムまたはプロセスのモデルにすることです。 DDDを使用する場合、実際のシステムがどのように機能するかを説明できるドメインエキスパートと密接に連携する必要があります。たとえば、競馬の賭けを処理するシステムを開発している場合、ドメインの専門家は経験豊富なブックメーカーかもしれません。
自分とドメインエキスパートの間で、ユビキタス言語（UL）を構築します。これは基本的にシステムの概念的な説明です。アイデアは、ドメインの専門家がそれを読み、それが正しいことを確認できるように、システムが行うことを書き留めることができるはずだということです。賭けの例では、ユビキタス言語には「人種」、「ベット」、「オッズ」などの単語の定義が含まれます。
ULで説明されている概念は、オブジェクト指向設計の基礎を形成します。 DDDは、オブジェクトの相互作用に関する明確なガイダンスを提供し、オブジェクトを次のカテゴリに分類するのに役立ちます。
- サブオブジェクトを持つ可能性のある値を表す値オブジェクト（たとえば、日付に日、月、年がある場合があります）
- identityを持つオブジェクトであるエンティティ。たとえば、各Customerオブジェクトには独自のIDがあるため、同じ名前の2人の顧客は同じ顧客ではないことがわかります
- 集約ルートは、他のオブジェクトを所有するオブジェクトです。これは複雑な概念であり、所有者がいなければ意味をなさないオブジェクトがあることに基づいて機能します。たとえば、「Order Line」オブジェクトは「Order」に属していないと意味をなさないため、Orderは集約ルートであり、Order LineオブジェクトはOrderオブジェクトのメソッドを介してのみ操作できると言います。
DDDはいくつかのパターンも推奨しています。
- リポジトリ 、永続化のパターン（通常はデータベースとの間でデータを保存およびロード）
- 工場 、オブジェクト作成のパターン
- サービス、ドメイン自体の一部にならずにメインドメインオブジェクトを操作するオブジェクトを作成するためのパターン
さて、この時点で、これらのことを聞いたことがないなら、期限のあるプロジェクトでDDDを使用しようとすべきではない、と言わざるを得ません。 DDDを試す前に、 デザインパターン および エンタープライズデザインパターン に精通している必要があります。これらを知ることで、DDDを理解しやすくなります。また、上記のように、InfoQから DDDの無料紹介 を入手できます（DDDに関する講演もあります）。
例としてStackOverflowを取り上げます。一部のWebフォームの設計を開始する代わりに、まずユーザー、質問、回答、投票、コメントなど、問題ドメイン内のエンティティのオブジェクト指向モデリングを行うことに集中します。設計は問題の詳細に基づいているためドメインと呼ばれるドメインドメイン駆動設計。
詳しくは Eric Evansの本 をご覧ください。