ドメイン駆動設計

ドメイン駆動設計（ドメインくどうせっけい、英語: domain-driven design、DDD）は主要なソフトウェア設計手法の一つであり^[1]、ドメインエキスパートの言葉に基づき、ドメインにおけるプロセスやルールをよく表現したドメインモデルを構築し、それに基づいてソフトウェア開発を行うことに主眼を置くものである^[2]^[3]^[4]。

DDDは以下のような目的に基づく。

プロジェクトにおける主な焦点を中核の業務領域と業務ロジックのレイヤーに置くこと
複雑な設計をドメインモデルで表現すること
技術者とドメインエキスパートの間にクリエイティブな協働関係を構築し、特定のドメイン問題を扱う概念的なモデルを継続的に洗練させること^[5]

DDDという名称は、エリック・エヴァンス（英語版）による著書の中で初めて提唱されたものである^[6]。

概要

DDDは、多くの高水準な概念と実践を明確に示している^[6]。

もっとも重要なものは、ソフトウェアにおける「ドメイン」であり、これはユーザがプログラムを適用する対象領域を指す。戦術的設計の一つであるドメインモデルパターンにおいては、ソフトウェアの開発者は「ドメインモデル」を構築する。これは特定のドメインのある側面を表現し、ドメインにおける問題を解決するために用いることができるような抽象化のシステムである。

DDDは大きく戦術的設計と戦略的設計に分けられる^[誰?]。

戦略的設計では、同じ言葉、区切られた文脈という概念の導入と、事業活動をその性質によって複数の業務領域に分類することを行う。事業活動は、中核の業務領域（コアドメイン）、一般的な業務領域（ジェネリック・サブドメイン）、補完的な業務領域（サブドメイン）に分類される^[7]。

戦術的設計では、DDDにおける戦略を達成するために、具体的にどのように業務ロジックを表現し、ソフトウェアを実装するかという点についての議論を行う^[7]。業務ロジックの表現方法としては、トランザクションスクリプト、アクティブレコード、ドメインモデル、イベント履歴式のドメインモデルなどが挙げられる^[7]。

戦略的設計

言葉の意味と文脈

DDDにおいては、ドメインエキスパートと技術者間で同じ言葉を用いることによって、業務に対する共通理解を形成する^[7]^[8]。ただし、同じ事業領域内においても、背景が異なれば異なった意味を持つ言葉が存在する。この曖昧さを解消するために、DDDでは区切られた文脈という概念を導入する^[7]。

同じ言葉（ユビキタス言語）

同じ言葉、あるいはユビキタス言語（英語: Ubiquitous language）とは、同じ言葉を使うことでドメインエキスパートと技術者間の効率的な意思伝達を促す、DDDにおける戦略的手法のことである。区切られた文脈内において、同じ言葉は同じ意味を持つ。DDDでは、技術者がドメインエキスパートと協力しながら同じ言葉を育て、特定のドメイン問題を扱うモデルの継続的な洗練を目指す^[7]。

ソフトウェアコード（e.g. クラス名、クラスメソッド、クラス変数）における言葉や構造はビジネスドメインに一致する。例えば、ソフトウェアがローン申請(loan application)を処理する場合、ソフトウェアは「loan application」「customer」といった名前のクラスや「accept offer」「withdraw」といったメソッドを持つことが考えられる。

区切られた文脈（境界づけられたコンテキスト）

区切られた文脈、あるいは境界づけられたコンテキスト（英語: Bounded context）とは、同じ言葉に同じ意味を適用できる範囲のことである。区切られた文脈は、ソフトウェア設計の観点で、ソフトウェア技術者が決定する^[7]。

マーティン・ファウラーによれば、ドメインが大きくなるにしたがって、単一の統一されたモデルを構築することは難しくなる^[9]。これは、事業領域において、同じ言葉でも文脈によって異なる意味を持つ場合が出てくるためである^{[注釈 1]}。

DDDではシステム全体が単一の統一されたモデルを持つという考え方に反対し、システムを複数の区切られた文脈に分けることを推奨する。区切られた文脈はそれぞれが自らのモデルを持つ^[10]。

計算機科学における難題は二つしかない。それはキャッシュの無効化と、命名である。ーフィル・カールトン^[11]

区切られた文脈は言語学における「意味論的な領域（英語版）」に基づいているとされる。意味論的な領域とは、同じ言葉が同じ意味で使われる範囲のことを指し、例えば「トマト」が植物学的な文脈では「果実」である一方で、法的^{[注釈 2]}な文脈では「野菜」であるようなことが挙げられる^[7]。

業務領域の分類

DDDにおいて、ソフトウェアは中核の業務領域と、一般的な業務領域、補完的な業務領域に分けられる。DDDにおける重要かつ主要な目的の一つは、戦力を中核の業務領域に集中させることであるとされる^[12]。

あるソフトウェアにおいて中核の業務領域であっても、他のソフトウェアにとっては一般的な業務領域であることはあり得る。

中核の業務領域

中核の業務領域（英語: Core subdomain）は、プロジェクトのコアとなる複雑で重要なロジックを含む部分である。ドメインモデルなどの複雑な業務ロジックを扱うためのデザインパターン（戦術的設計）を選択することが考えられる。事業において戦略上強みとなる部分であり、頻繁な変更が考えられる^[7]。

一般的な業務領域

一般的な業務領域（英語: Generic subdomain）はどのソフトウェアにおいても基本的にアプローチが変わらないような部分であり、したがって外部のソフトウェアやライブラリを活用することが考えられるとされる^[7]。例としては認証処理などが挙げられる。

補完的な業務領域

補完的な業務領域（英語: Supporting subdomain）は、事業活動を支えるものの、競争優位を生み出さない部分である。補完的な業務領域のロジックは単純かつ変更が少ないとされ、トランザクションスクリプトやアクティブレコードなどの簡易な業務ロジックの表現方法を用いることが適しているとされる^[7]。

戦術的設計

戦術的設計では、具体的にどのようにソフトウェアを実装するかという問題を取り扱う。以下はDDDにおける主要な技術方式である。

業務ロジックの表現方法

ヴラド・コノノフは、シンプルな業務ロジックに対する実装方法としてトランザクションスクリプトとアクティブレコード、複雑な業務ロジックに対するデザインパターンとしてドメインモデル、それを時系列に拡張したものとしてイベント履歴型のドメインモデルを挙げている^[7]。

トランザクションスクリプト

トランザクションスクリプト（英語: Transaction Script）は手続き的な業務ロジックの実装方法であり、プレゼンテーション層から渡されるリクエストを処理する一連の流れの中で業務ロジックを表現する^[7]^[13]。

アクティブレコードパターン

アクティブレコード（英語: Active Record）はドメインモデルの一種であり、モデルがDBのテーブルあるいはビューと一対一に対応する。アクティブレコードのオブジェクトはDBにおけるテーブルのレコードを表現し、レコードを表現するオブジェクト自身が永続化などのデータアクセス処理を行う^[7]^[14]。

アクティブレコードを用いるメリットとしては、構造がシンプルで、データベース操作が直感的になるということがある。アクティブレコードを用いた場合でも、業務ロジックはトランザクションスクリプトとして記述する。この場合、コードはDBを直接操作するのではなく、アクティブレコードオブジェクトを操作する^[7]^[15]。

アクティブレコードのデメリットとしては、テーブルとモデルが一対一に対応していることから、モデルがデータベースの構造に依存することと、ドメインモデルとしての柔軟性を欠くという点が挙げられる。

アクティブレコードの目的は、DB操作の最適化であるとされる^[7]。

ドメインモデルパターン

ドメインモデル（英語: Domain Model）は、業務ロジックとデータの両方を一体化させた、事業活動を表現するオブジェクトモデルである^[16]。ドメインモデルは他の層の知識に依存せず業務知識を表現することが望ましいとされ、その点で後述のポートとアダプタパターンと相性が良い^[7]。

典型的なドメインモデルは集約とそれを構成するエンティティ、値オブジェクト、ドメインサービスによって表現される。集約はドメインモデルの永続化におけるトランザクションの単位であり、業務ロジックはエンティティや値オブジェクトのフィールド、あるいはメソッドとして定義されるのに加え、それらに定義することが不自然であったり、ロジックが集約を跨いで存在する場合、これはドメインサービスによって表現される^[7]。

ドメインモデルが持つべき情報がドメインモデルの外に書かれており、業務知識が漏れ出している状態を、「ドメインモデル貧血症」と呼ぶことがある^[17]。

イベント履歴式のドメインモデル

イベント履歴式のドメインモデルでは、集約の状態変化をドメインイベントで表現する。ドメインモデルパターンでは集約の状態を永続化するのに対し、イベント履歴式のドメインモデルでは集約の状態の変化を表すドメインイベントを永続化する^[7]。

このパターンにおいては過去のある時点においての状態を得ることができるというメリットがある一方で、現在の状態を再現するために計算が必要になるというデメリットがある。これについては、テーブルが更新されるたびに最新の状態を投影したビューを更新し、CQRSパターンを用いて読み込みモデルからはこちらを参照することで対応できるとされる^[7]^[18]。

アーキテクチャ方式

階層化アーキテクチャ

ソフトウェアの階層化は情報技術において一般的な考え方の一つである^[要出典]。例えば、コンピュータネットワークの分野においては、OSI参照モデルが階層化アーキテクチャとして挙げられる。

アプリケーションレベルのソフトウェアアーキテクチャにおいては、以下に示すようないくつかのアーキテクチャパターンが知られている。

レイヤードアーキテクチャ

古典的な三層レイヤードアーキテクチャでは、技術的な関心に基づいて、アプリケーションをプレゼンテーション層、ドメインロジック層、データアクセス層の三層に分ける^[7]^[19]。

ポートとアダプタ方式

→詳細は「ポートとアダプタ」を参照

ポートとアダプタ方式では、依存性の逆転を行うことによって、古典的レイヤードアーキテクチャにおけるドメインロジック層がデータアクセス層に依存することを回避する。この方式に基づいたアーキテクチャモデルとしては、オニオンアーキテクチャ、クリーンアーキテクチャ、ヘキサゴナルアーキテクチャが知られる^[7]。

これらのアーキテクチャは複数の層を持つ円として表現され、内層は外層の知識に依存しない。アーキテクチャの中心にはドメインロジックが存在し、中心のドメインロジックが他の何にも依存しないという性質から、これらのアーキテクチャを用いることによって、ドメインモデルが具体的なインフラストラクチャ層の知識に依存することを回避することができる^[7]。

クリーンアーキテクチャを提唱したロバート・マーチン（英語版）によれば、奥に行くほどソフトウェアのレベルは高くなり、外層はメカニズムで、内層はポリシーであるとされる^[20]。

依存性逆転の原則

→詳細は「依存性逆転の原則」を参照

CQRS（コマンドクエリ責任分離）

→詳細は「コマンドクエリ責任分離」を参照

実装の選択

ドメインモデルパターンでは、開発者がドメインモデルを純粋で有用な構造として維持するためには、通常大量の分離とカプセル化を行う必要がある一方で、保守性などの利点を提供するため、Microsoftは、ドメインに対する共通理解を構築することで明確な利点のある複雑な業務領域にのみドメインモデルパターンを導入することを推奨している^[3]^{[注釈 3]}。

ドメインモデルの構成要素

典型的なドメインモデルは集約とそれを構成するエンティティ、値オブジェクトに加え、ドメインサービスといった要素からなる。集約は複数のエンティティからなり、永続化においてデータの一貫性が必要とされるトランザクションの単位である。集約においてルートとなるエンティティが永続化におけるインターフェースとなる^[7]。例えば、BookとStockというエンティティがあり、これらがBook集約を形成しているとすると、ここでのルートはBookエンティティである。

エンティティは識別子によって同一性が識別され、エンティティや値オブジェクトによって状態が表現されるミュータブルなオブジェクトである。例えば、ほとんどの航空会社はすべてのフライトにおいて席に対して一意の数字を割り当てている。これは席の識別子である。一方で値オブジェクトは属性の組み合わせによって同一性が識別されるイミュータブルなオブジェクトである^[7]^{[注釈 4]}。例えば、ある人が名刺を交換する際を例に挙げると、この時名刺を交換する人は名刺の内容（属性）のみに関心があり、名刺一枚一枚を個別に扱うことはない。

ドメインサービスは、エンティティや値オブジェクトに実装することが不自然な業務ロジックを実装するためのステートレスなオブジェクトである^[7]。

集約の永続化には、リポジトリパターンが用いられることが一般的である。ここでのリポジトリは集約の入出力の単位のインターフェース（ポート）として用いられる^[21]^[22]。典型的なパターンでは、インフラストラクチャ層がドメインモデルのポートを実装し、ユースケースがリポジトリを用いて集約の出し入れを行う。

他の概念との関係

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

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

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