値オブジェクト

ドメイン駆動設計で、金額や住所のように、識別子を持たず、属性の値そのものによって等しいかどうかが決まるオブジェクト。生成した後に値を変えない（不変にする）のが原則で、値を変えるときは新しいオブジェクトに置き換える。

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

ドメイン駆動設計で、特定のエンティティや値オブジェクトに持たせると不自然になる業務上の処理を、独立して表すオブジェクト。ドメインサービスとも呼ぶ。口座間の振替のように複数のエンティティにまたがる計算や判定を担い、それ自体は状態を持たない。画面やデータベースの操作の手順を調整するアプリケーションサービスとは区別される。

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

ドメイン駆動設計で、属性の値ではなく一意な識別子によって同一性が保たれるオブジェクト。顧客や注文のように、属性が変わっても同じものとして追跡する必要があるものが当たり、ライフサイクルを通じて状態が変化する。値そのもので等しいかどうかが決まる値オブジェクトと対比される。

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

業務の機能（プロセス）とデータ（エンティティ）の組合せごとに、生成（Create）、参照（Read）、更新（Update）、削除（Delete）のどの操作を行うかを表にまとめたもの。データを生成・削除する機能の漏れや、機能とデータの対応の矛盾を確かめ、システムの範囲の決定やサブシステムの分割に使う。

コマンドクエリ責務分離。データを更新する処理（コマンド）と参照する処理（クエリ）のモデルを分けるアーキテクチャパターン。更新と参照で別のデータモデルやデータストアを使い、それぞれを独立して最適化・拡張できる。更新の結果が参照のモデルに反映されるまでに遅れが生じることがある。