ドメイン駆動設計用語集 | これで理解できるドメイン駆動設計！
Prev: 旅立ち
付録として、ドメイン駆動設計そのものや、関連する話題で出てくる用語について短い解説をまとめます。
ドメイン駆動設計の中核用語
ドメイン
ソリューションを提供するために分析しなければならない範囲のこと。やり取りされる情報、関係する人や会社、物、あるいはそれらの動き、関係する法律、社内のルールなどソリューションを提供するために調べ、考え、分析する必要のある、ありとあらゆる物事が存在する範囲のこと。
ドメインとはも参照。
モデル
伝えたい事柄について、受け手に必要な情報を伝達しつつ、不要な側面は含んでいないモノや図、文章、数式などで表現されたもののこと。
ドメインモデル
ドメインを分析した結果を伝えるために作成するモデルのこと。
モデリング
ドメインモデルを作成する活動のこと。
ドメイン駆動設計
ドメインを分析してドメインモデルを明らかにしドメインモデルが実装に反映されるように設計を行う設計手法のこと。
ドメイン駆動設計とはも参照。
ユビキタス言語
あらゆる場面で、同じ言葉やドメインモデル、ビジネスルールのフレーズなどを使う振る舞いのこと。あるいは、その統一された同じ言葉やドメインモデル、ビジネスルールのフレーズのこと。
ドメイン駆動設計の核心も参照。
モデル駆動設計
作成したモデルが実装に反映されるように設計を行う設計手法のこと。ここでいうモデルはドメインモデル以外のモデルの場合もありえます。ドメイン駆動設計はモデルをドメインモデルに限定したモデル駆動設計とも言えます。
ドメイン駆動設計の戦術的設計とはおよびドメイン駆動設計の核心も参照。
実践的モデラ
モデリングを行う人が分析だけを行うのではなく、実装も行うことで絵に描いた餅のようなモデルをつくらないようにせよという意味。逆に実装を担当するプログラマがモデルにも注意を払うことで、実装とモデルが乖離しないようにせよという意味。
ドメイン駆動設計の核心も参照。
戦術的設計
戦術的設計
エリック・エヴァンスのドメイン駆動設計に出てくる、設計パターン（ApplicationService、DomainService、Module（Package）、Aggregate、Entity、ValueObject、Specification、Repository、Factory）のこと。
ただし、戦術的設計という言葉はエリック・エヴァンスのドメイン駆動設計には出てこず、実践ドメイン駆動設計に出てくる言葉。
軽量DDD
戦術的設計の設計パターンを適用するだけで、ユビキタス言語、モデル駆動設計、実践的モデラを実践しない設計手法のこと。ドメイン駆動設計を実践しているとは言えない設計手法。
ただし、軽量DDDという言葉はエリック・エヴァンスのドメイン駆動設計には出てこず、実践ドメイン駆動設計に出てくる言葉。
レイヤードアーキテクチャ
ユースケース（アプリケーション）レイヤ、ドメインレイヤ、インフラストラクチャレイヤレイヤのように役割ごとにレイヤを分けたアーキテクチャの総称。エリック・エヴァンスのドメイン駆動設計の「レイヤー化アーキテクチャ（LAYERED ARCHITECTURE）」の冒頭に出ている図のようなアーキテクチャ構造は一例であり、この図の構造だけがレイヤードアーキテクチャというわけではありません。
Clean Architecture 達人に学ぶソフトウェアの構造と設計に出てくるクリーンアーキテクチャや、オニオンアーキテクチャもレイヤードアーキテクチャの一種。
ApplicationService
アプリケーションの機能のエンドポイントとして作成される設計パターン。Controllerやバッチスクリプト、あるいはrails consoleのようなエンジニアが対話的にコードを実行する時に実行するときに呼ばれることが想定されます。
DomainServiceやAggregateを実装するならドメインロジックは実装しません。
ドメイン駆動設計の戦術的設計とはも参照。
DomainService
ドメインロジックが複雑だがAggregateを作るほどではない場合に作成されるトランザクションスクリプト、または、複数のAggregateを連携させてドメインロジックを実行するFacadeパターンを実現するために作成する設計パターン。
ドメインロジックを実装したもの。
ドメイン駆動設計の戦術的設計とはも参照。
Module（Package）
DomainModelを整理するために作成されるディレクトリやパッケージのこと。
ドメインモデルに対応します。
ドメイン駆動設計の戦術的設計とはも参照。
Aggregate
データの一貫性を保持する単位。複数のEntityから構築されたクラス群。起点となるEntityはルートと呼ばれます。
ドメインモデルに対応し、ドメインロジックを実装します。
ドメイン駆動設計の戦術的設計とはも参照。
Entity（参照オブジェクト：ReferenceObject）
何らかの識別子をもち、その識別子のみによってインスタンスが等価か判断される設計パターン。
ドメインモデルに対応し、ドメインロジックを実装します。
ドメイン駆動設計の戦術的設計とはも参照。
ValueObject（値オブジェクト）
持っているメンバ変数が完全に一致した場合にインスタンスが等価と判断される設計パターン。
ドメインモデルに対応し、ドメインロジックを実装します。
ドメイン駆動設計の戦術的設計とはのValueObjectの説明と末尾のコラムも参照。
Specification
他のEntityやValueObjectに実装すると本来の責務を圧迫してしまったり、いずれのクラスも実装場所が適切でないビジネスルールがある場合に適用する設計パターン。
ドメインモデルに対応し、ドメインロジックを実装します。
ドメイン駆動設計の戦術的設計とはも参照。
Repository
Aggregateを永続化したり、永続化したデータからAggregateのインスタンスを復元する役割の設計パターン。データベースなどとAggregateのインピーダンスミスマッチを解消するのが役割。
ドメインモデルには対応しません。Repositoryを作るならば、対応するAggregateが存在します。
ドメイン駆動設計の戦術的設計とはも参照。
Factory
Aggregateのインスタンスを構築することに特化した役割の設計パターン。クラスを作ることもあるし、明確なFactoryとして作らずにRepositoryの中の処理、Aggregateのルートなどで役割をになってしまうことがあります。
ドメイン駆動設計の戦術的設計とはも参照。
戦略的設計
エリック・エヴァンスのドメイン駆動設計の「第4部 戦略的設計」で紹介されている各パターンの総称。
一枚岩のシステムとして構築するには複雑すぎるために、システム全体レベルで分割統治が必要な場合に利用するパターン群。逆に言えばシステム全体レベルで分割統治が必要ないなら関係がないパターン群です。
ざっくり言って、
- ユビキタス言語が衝突しないように、通用するコンテキストをわける（境界づけられたコンテキスト、コンテキストマップなど）
- コンテキスト間の連携のために、モデルの変換や対応について考える（コンテキストマップ、共有カーネル、腐敗防止層など）
- 注力するべきドメインとそうでないドメインがあり、注力するべきドメインを区別できるようにし、定義を明確にし、範囲と定義を継続的に改善する（コアドメイン、ドメインビジョン声明文、隔離されたコアなど）
というような内容です。
コンテキストをわけないとユビキタス言語の衝突を管理できないほど大規模であるとか、連携しなければならないレガシーシステムがすでにあるとか、注力するべき部分をはっきりさせないと区別できないとか、そういった境界を必要とする場合に使われるのが戦略的設計です。
気が向いたら個々の説明について追記するかもしれない。
その他
問題空間（Problem Space）、問題領域（Problem Domain）
実践ドメイン駆動設計で出てくるため、ドメイン駆動設計と関連深いように思えますが、実際にはソフトウェア工学分野の言葉のようです。
問題空間は要求分析で分析する対象のこと。つまり、この書籍におけるドメインのことを指します。
個人的には認識する価値の薄い言葉であると思っています。
ソフトウェア工学 p. 98 も参照。
解決空間（Solution Space）、解決領域（Solution Domain）、解空間
実践ドメイン駆動設計で出てくるため、ドメイン駆動設計と関連深いように思えますが、実際にはソフトウェア工学分野の言葉のようです。
問題空間を分析して明らかになった問題を解決するために設計を行うわけですが、このとき決まった設計が蓄積されるのが解決空間です。
個人的には認識する価値の薄い言葉であると思っています。
ソフトウェア工学 p. 98 も参照。