ドメイン駆動設計

ドメイン駆動設計（、DDD）とは、ドメインの専門家からの入力に従ってドメインに一致するようにソフトウェアをモデル化することに焦点を当てるソフトウェア設計手法である。オブジェクト指向プログラミングに関しては、ソースコード（クラス名・クラスメソッド・クラス変数）の構造と名称がビジネスドメインと一致させる必要があることを意味する。例えばローンの申し込みを処理するソフトウェアには、"LoanApplication"や"Customer"などのクラスと、"AcceptOffer"や"Withdraw"どのメソッドが含まれることになる。ドメイン駆動設計は次の目標に基づいている。
ドメイン駆動設計では、開発者は通常モデルを純粋で有用な構造として維持するために大量の分離とカプセル化を実装する必要があると批判されているが、ドメイン駆動型設計は保守性などの利点を提供する。一方でMicrosoftは、モデルがドメインの共通理解を策定する上で明確な利点を提供する複雑なドメインにのみ推奨している。この名称は、Eric Evansが著作"Domain-Driven Design: Tackling Complexity in the Heart of Software"で用いた。
概要.
ドメイン駆動型設計は、多くの高レベルの概念と実践を明確に示している。最も重要なのは"ドメイン"であり、ユーザーがプログラムを適用するサブジェクト領域は、ソフトウェアのドメインである。ソフトウェアのドメインは、その"コンテキスト"、つまり、その意味を決定する単語またはステートメントが表示される設定を管理する。このことから、開発者は"ドメインモデル"を構築する。これは、ドメインの選択された側面を記述し、そのドメインに関連する問題を解決するために使用できる抽象化のシステムである。ドメイン駆動設計のこれらの側面は、"ユビキタス言語"を促進することを目的としている。つまり、ドメインモデルは、システム要件、ビジネスユーザー、スポンサー、および開発者を記述するためにドメインの専門家によって共有される"common language"（共通言語）を形成するべきである、という考えである。ドメイン駆動設計では、はオブジェクト指向の多層アーキテクチャのの1つである。
モデルの種類.
ドメイン駆動設計は複数の種類のモデルを区別している。例えば"エンティティ"は、属性ではなくIDによって定義されるオブジェクトである。例としてほとんどの航空会社はすべてのフライトの座席に一意のIDを割り当てて識別している。対照的に"値オブジェクト"は、属性を含むが概念的なアイデンティティを持たない不変オブジェクトである。例えば、人々が名刺を交換するとき、一意の名刺を区別しようとはせず、名刺に書かれた情報（属性）だけを利用する。モデルは"イベント"（過去に起こったこと）を定義することもできる。ドメインイベントとは、ドメインの専門家が関心を持っているイベントである。モデルはルートエンティティによって結合され、"集約"になることができる。集約外のオブジェクトはそのルートへの参照を保持できる一方で集約の他のオブジェクトへの参照は保持できない。集約ルートは、集約内の変更の一貫性をチェックする。例えば、ドライバーは車の各ホイールを個別に制御する必要はなく単に車を運転するだけである。このコンテキストでは、車は他のいくつかのオブジェクト（エンジン、ブレーキ、ヘッドライトなど）の集約と言える。
モデルの操作.
ドメイン駆動型設計では、オブジェクトの作成はオブジェクト自体から切り離されることがよくある。例えば"リポジトリ"は、データストア（データベースなど）からドメインオブジェクトを取得するためのメソッドを備えたオブジェクトであり、同様にファクトリはドメインオブジェクトを直接作成するためのメソッドを持つオブジェクトである。プログラムの機能の一部が概念的にどのオブジェクトにも属さない場合、通常はサービスとして表現される。
ドメイン駆動設計をサポートするソフトウェアツール.
ドメイン駆動開発の実践は、特定のソフトウェアツールやフレームワークに依存したものではない。しかし、多数のオープンソースツールとフレームワークがEvansの書籍で推奨しているパターンや、ドメイン駆動開発の方法をサポートしている。以下のようなものがある。