ドメイン駆動設計

ドメイン駆動設計（英: domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする^[1]。この名称は、 Eric Evans が同名の著作で用いた^[2]。

書籍 Domain-Driven Design^[2]では、たとえば ubiquitous language といった高位の概念と実践について多数述べられている。これは、ドメインモデルがシステムの要求を記述するためにドメインの専門家が提供し、業務上のユーザーやスポンサー、開発者みなにとってうまく働くような common language(共通言語)を形成するべきである、という考えである。同書は多層アーキテクチャを持つオブジェクト指向システムにおいて、一般的なレイヤ構造におけるドメイン層を記述することに重点を置いている。

ドメイン駆動設計では、ドメインモデルを表現する要素として、下記のものを挙げている。

エンティティ (参照オブジェクト): ドメインモデル内のオブジェクトであり、その属性によってではなく、連続性と識別性によって定義される。
値オブジェクト: 事物の特性を記述するオブジェクトである。特に識別する情報はなく、通例、読み出し専用のオブジェクトであり、Flyweight パターンを用いて共有できる。
サービス: 操作がオブジェクトに属さない場合に、問題の自然な解決策として、操作をサービスとして実現することができる。サービスの概念は、GRASPにおいて"純粋人工物"と呼ばれるものである。
リポジトリ:ドメインオブジェクトを取得するメソッドは、記憶域の実装を簡単に切り替えられるようにするため、専門のリポジトリオブジェクトに処理を委譲するべきである。
ファクトリー : ドメインオブジェクトを生成するメソッドは、実装を簡単に切り替えられるようにするため、専門のファクトリーオブジェクトに処理を委譲するべきである。

他の概念との関係[編集]

オブジェクト指向分析設計: ドメイン駆動設計の考え方は、理論上、オブジェクト指向の手法に制約されるものではない。実際、ドメイン駆動設計では、オブジェクト指向の技法が実現する強みを活かそうとしている。
モデル駆動工学 (MDE)
モデル駆動型アーキテクチャ (MDA): MDA の考え方は、ドメイン駆動設計と両立するが、二つの概念の意図するところは多少異なっている。MDA は、ドメインモデルをよりよく定義する方法よりも、技術の異なるプラットフォームに対してモデルをコードに変換する方法の方に関心がある。
POJO と POCO: POJOとPOCOは実装上の考え方であり、それぞれJavaと.NET Frameworkに固有のものである。しかし、POJOとPOCOという用語が現れたことは、二つのプラットフォームのいずれかにおいて、特定のテクノロジの要求に応じてではなく、純粋に対応するドメインの概念のビジネス上の振る舞いを実現するためにドメインオブジェクトが定義されるべきである、という考え方が広まりつつあることを示している。
Naked Objectsパターン: このパターンは、次の二つの仮定に基づいている^[3]。

良質なドメインモデルがあれば、ユーザインターフェイスは、単純にドメインモデルを反映したものになる。
ドメインモデルを直接反映したユーザインターフェイスが必要であれば、より良いドメインモデルの設計を余儀なくされる。

ドメイン固有言語 (DSL): ドメイン駆動設計は、必ずしもDSLを必要としないが、DSLを定義し、domain-specific multimodelingのような手法の実践を助ける。
アスペクト指向プログラミング (AOP): AOPを用いると、技術的な関心（セキュリティ、トランザクション管理、ロギング）をドメインモデルから簡単にくくりだすことができ、純粋にビジネスロジックに焦点をおいたドメインモデルの設計と実装を容易にする。