DDD（ドメイン駆動設計）

ビジネスドメイン（業務領域）の知識を中心に据えてソフトウェアを設計する手法。ドメインモデル、ドメインロジック、ユビキタス言語などの概念を用い、業務の複雑さをソフトウェアに正確に反映する。DDDと略される。

業務ドメインの知識を中心にソフトウェアを設計する手法。ドメインモデル、ドメインロジック、コンテキストマップ、ユビキタス言語、エンティティ、値オブジェクト、サービスなどの概念を用いて、業務の本質をコードに反映する。

ビジネスドメインの知識を中心に据えてソフトウェアを設計する手法。ユビキタス言語、境界づけられたコンテキスト、集約、エンティティ、値オブジェクトなどの概念を用いる。Eric Evansが提唱した。

ビジネスドメインの知識を中心に据えてソフトウェアを設計する手法。ユビキタス言語、境界づけられたコンテキスト、集約、エンティティ、値オブジェクトなどの概念を用いる。Eric Evansが提唱した。

ドメイン駆動設計で、ソフトウェアによって課題を解決しようとする業務上の対象領域。例えば保険のシステムなら、契約、保険料、保険金の支払などの業務の知識とルールの範囲を指す。ドメインの知識を整理して表したものがドメインモデルで、大きなドメインは境界づけられたコンテキストに分けて扱う。関係モデルの定義域（ドメイン）とは別の意味である。

ドメイン駆動設計で、業務の専門家と開発者が共通して使う、ドメインの用語と意味をそろえた言語。会話、文書、ソースコードのクラス名やメソッド名にまで一貫して使い、認識のずれや言い換えによる誤解を防ぐ。境界づけられたコンテキストごとに定める。

ドメイン駆動設計で、特定のドメインモデルとユビキタス言語が一貫して通用する範囲。同じ「顧客」という語でも販売と配送では意味や属性が違うため、範囲を区切ってモデルを分ける。マイクロサービスの分割の単位を考える手掛かりにもなる。

ドメイン駆動設計で、対象となる業務領域（ドメイン）の概念、ルール、概念どうしの関係を整理し、ソフトウェアの構造として表したモデル。業務の専門家と開発者がユビキタス言語を使って作り、ソースコードと一致させ続ける。

ドメイン駆動設計で、識別子を持たず、属性の値だけで同一かどうかが決まるモデル要素。金額、住所、期間などが該当し、一般に生成後に値を変えない不変（イミュータブル）なものとして扱う。同一性で区別するエンティティと対になる。

ドメイン駆動設計で、属性の値ではなく一意な識別子によって同一性が保たれるモデル要素。顧客や注文のように、属性が変わっても同じものとして追跡する必要があるものが該当する。値だけで区別する値オブジェクトと対になる。