ドメイン駆動設計 (DDD) とは何ですか? [closed] 質問する

まず、DDD が必要であることがわからない場合は、必要がない可能性があります。DDD が解決する問題を認識していない場合は、それらの問題がない可能性があります。DDD の支持者でさえ、DDD は大規模な (6 か月を超える) プロジェクトのみを対象としていると頻繁に指摘します。

この時点でまだ読んでいると仮定すると、DDD に関する私の見解は次のとおりです。

DDDは、ソフトウェアを現実世界のシステムやプロセスのモデルにしようとするものです。DDDを使用する場合は、ドメイン専門家現実世界のシステムがどのように機能するかを説明できる人。たとえば、競馬の賭けを扱うシステムを開発している場合、ドメイン エキスパートは経験豊富なブックメーカーである可能性があります。

あなたとドメイン エキスパートの間で、ユビキタス言語(UL) を構築します。これは基本的にシステムの概念的な説明です。ドメイン エキスパートが読んで正しいかどうかを確認できるような方法で、システムの機能について記述できるようにするのが目的です。この賭けの例では、ユビキタス言語には「レース」、「賭け」、「オッズ」などの単語の定義が含まれます。

UL で説明されている概念は、オブジェクト指向設計の基礎となります。DDD は、オブジェクトがどのように相互作用するかについて明確なガイドラインを提供し、オブジェクトを次のカテゴリに分類するのに役立ちます。

• 値オブジェクトは、サブパーツを持つ可能性のある値を表します（たとえば、日付には日、月、年が含まれる場合があります）。
• エンティティは、アイデンティティを持つオブジェクトです。たとえば、各顧客オブジェクトには独自のアイデンティティがあるため、同じ名前の2人の顧客が同じ顧客ではないことがわかります。
• 集約ルートは、他のオブジェクトを所有するオブジェクトです。これは複雑な概念であり、所有者がいなければ意味をなさないオブジェクトが存在するという前提で機能します。たとえば、「注文明細」オブジェクトは、属する「注文」がなければ意味をなさないため、注文が集約ルートであり、注文明細オブジェクトは注文オブジェクトのメソッドを介してのみ操作できると言えます。

DDD では、いくつかのパターンも推奨されています。

• リポジトリ、永続性のためのパターン（通常はデータベースへのデータの保存と読み込み）
• 工場オブジェクト作成のパターン
• サービス：ドメインの一部にならずにメインのドメインオブジェクトを操作するオブジェクトを作成するためのパターン

さて、ここまでで、もしあなたがこれらのことを聞いたことがないのであれば、期限のあるプロジェクトでDDDを使おうとすべきではないと言わなければなりません。DDDを試す前に、以下のことをよく知っておく必要があります。デザインパターンそしてエンタープライズデザインパターンこれらを知っておくと、DDDの理解がずっと容易になります。そして、上で述べたように、DDDの無料入門InfoQ から入手可能 (DDD に関する講演も見つかります)。