【DDD】「ドメイン」、「境界付けられたコンテキスト」

ドメイン

企業には独自のルールや文化が存在しています。

分析対象となる問題領域（ビジネス課題）、全ての仕組みを理解するにはあまりに大きく複雑なため通常は「コアドメイン」と「サブドメイン」と言う適切なサイズに分割する。

組織を成功に導くために最も重要なもの。事業的に他と差別化されており最優先で取り組まれる。優秀なメンバーを参画させて積極的に成長させてビジネス的な差別化を図ります。

DDDで開発を行う場合はそれが本当にコアドメインなのかはチームメンバーで議論をしてしっかり把握する必要があります。

コアドメインほど重要じゃない業務です。

なお、当事者によってはコアとサブが入れ替わるので注意です。（例えば、EC構築とERPの事業があった場合に、EC構築メンバーからはERPはサブですし、ERPメンバーから見たらEC構築事業はサブドメインになります。）

業務的に特別だが、コアドメインほど重要じゃない。コアドメインの支援を行う独自機能など。

業務的に特別じゃないが、全体として必要(認証系、外部ERPなど、極端な話交換されたとしても差支えがない機能のことです。）

戦略的/業務的なドメインの問題を技術的なソリューションで解決する。（解決領域）

巨大なモデルを構築しないようにユビキタス言語の境界に従いコンテキストを複数に分割。(要は、一つの単語が複数の意味を持たないように適切にドメインを分割する）

「一つのコアドメイン（もしくはサブドメイン）」に一つの「境界づけられたコンテキスト」が対応している状態が最適だとされています。現実としては、「複数のドメイン」に「一つの境界づけられたコンテキスト」が対応しているケースが多いようです。

一つの境界づけられたコンテキストは一つのチームで担当します。ドメインエキスパートは一人置いて一人のエキスパートがユビキタス言語を定義してできるだけシンプルなモデルを構築します。

「商品」と言う単語は、システムの状態によって複数の表現をします。

販売されている状態なら「在庫品」ですし、販売後は「出庫品」などと表現します。

一つの単語が複数の意味を持たないように適切にプログラムを分割して複雑化を防ぎます。

境界づけられたコンテキストを設計する場合、アーキテクチャ、タスク分割、成果物などの影響は受けないようにする。