ドメイン駆動設計は、問題ドメイン内のアクティビティ、タスク、イベント、およびデータをソリューションドメインのテクノロジーアーティファクトにマッピングすることに重点を置いた複雑なシステムの開発のための方法論とプロセスの処方です。
ドメイン駆動設計の重点は、問題ドメインを理解して、特定のテクノロジーのセットに実装できる問題ドメインの抽象的なモデルを作成することです。方法論としてのドメイン駆動設計は、このモデル開発と技術開発が、問題ドメインの変化に直面しても堅牢でありながら、それを使用する人々のニーズを満たすシステムをどのようにもたらすかについてのガイドラインを提供します。
ドメインドリブンデザインのプロセス側には、問題のドメインを知っているドメインの専門家とソリューションドメインを知っているデザイン/アーキテクチャの専門家の間のコラボレーションが含まれます。これらの2つの異なるドメインの2つの異なる視点を持つ人々が2つの異なる視点でソリューションについて話し合うとき、彼らは実際に共有された概念を持つ共有されたナレッジベースについて話し合うように、アイデアは共有言語で共有されたモデルを持つことです。
特定のシステムを必要とする人々とシステムを設計および実装している人々の間で共有された問題ドメインの理解の欠如は、プロジェクトを成功させるための中心的な障害のようです。ドメイン駆動設計は、この障害に対処するための方法論です。
それは、オブジェクトモデルを持つ以上のものです。問題のドメイン内の実際のニーズを発見し、それらのニーズを満たすために適切なソリューションを作成できるように、焦点は本当に共有コミュニケーションとコラボレーションの改善にあります。
ドメイン駆動設計：善と挑戦はこのコメントで簡単な概要を提供します：
DDDは、トップレベルのアーキテクチャを発見し、ソフトウェアが複製する必要があるドメインのメカニズムとダイナミクスについて通知するのに役立ちます。具体的には、適切に行われたDDD分析により、ドメインの専門家とソフトウェアアーキテクトの間の誤解が最小限に抑えられ、その後の高額な変更要求の数が減少します。DDDは、ドメインの複雑さを小さなコンテキストに分割することにより、プロジェクトアーキテクトに肥大化したオブジェクトモデルを設計するように強いることを避けます。会議室のホワイトボードのサイズ。
短い例を提供するこの記事「サービスアーキテクチャのドメイン駆動設計」も参照してください。この記事では、ドメイン駆動設計の以下のサムネイルの説明を提供します。
ドメインドリブンデザインは、ビジネスの現実に基づいたモデリングを、ユースケースに関連するものとして提唱しています。現在は古くなり、誇大宣伝のレベルが低下しているため、DDDアプローチが目前の問題を理解し、ソリューションの一般的な理解に向けてソフトウェアを設計するのに本当に役立つことを忘れています。アプリケーションを構築するとき、DDDは問題をドメインおよびサブドメインとして話します。問題の独立したステップ/領域を境界付きコンテキストとして説明し、これらの問題について話すために共通言語を強調し、実装をサポートするエンティティ、値オブジェクト、集約ルートルールなどの多くの技術的概念を追加します。
マーティン・ファウラーは、方法論としてのドメイン駆動設計が言及されている多くの記事を書いています。たとえば、この記事のBoundedContextは、ドメイン駆動開発の境界付きコンテキストの概念の概要を示しています。
当時、私たちはビジネス全体の統合モデルを構築するように勧められましたが、DDDは、「大規模システムのドメインモデルの完全な統合は実現可能ではないか、費用対効果が高くない」ことを認識しました1。そのため、代わりにDDDは大規模なシステムを境界付きコンテキストに分割し、それぞれが統一されたモデルを持つことができます-基本的に、MultipleCanonicalModelsを構造化する方法です。