はじめに
前回は「そもそもDDDとは？」というテーマを学習しました。
さて、今回は「DDDが扱う領域」について学習しましょう。システム開発においては、取り組むべき問題領域を分析して、課題を整理し、技術的取り組みを用いて解決します。特に概念の理解が難しい「ドメイン」や「境界づけられたコンテキスト」などについて整理しました。
全体像
まず、主要概念の全体像を紹介します。下の図を見てください。
広義のドメイン（チーム全体が取り組む事業全体）
├問題領域（課題の分析化と明確化）
| ├コアドメイン
| └サブドメイン
| ├支援サブドメイン
| └汎用サブドメイン
└開発領域（課題の解決）
└境界付けられたコンテキスト
では、それぞれの用語の意味について解説していきます。
ドメインとは？
ドメインという言葉を一言で説明すると、「対象とする事業が扱う世界」を表します。その世界には独自のルールや文化が存在します。チームの全員がその世界について深く理解することがよい開発には不可欠ですが、すべて理解するのはしんどいので上のように分割して考えます。
「コアドメイン」と「サブドメイン」
両者の違いは以下の通りです。
- コアドメイン
-
事業で最も重要で不可欠な部分。
優秀な人材を動員し、積極的に成長させる。 - サブドメイン
-
補助的な部分。
もちろん不要というわけではない。
コアドメインの部分に強みがない場合は、そもそもDDDで開発を行うべきか再検討する必要がある。
チーム全員が同じコア（サブ）ドメインを定義する必要はない。
当事者の得意分野に応じて両者は入れ替わる。
「支援サブドメイン」と「汎用サブドメイン」
上の図からもわかるように、サブドメインは二つに分かれています。先ほどと同じように両者の違いを説明します。
- 支援サブドメイン
- コアドメインほど重要ではないが特別なもの。
例：コアドメインの支援を行う独自機能 - 汎用サブドメイン
- 業務的に特別というわけではないが必要なもの。
例：認証機能
「境界づけられたコンテキスト」とは？
続いて、「境界づけられたコンテキスト」について解説します。
私が参考にした書籍には、「境界づけられたコンテキスト」とは戦略的、業務的ドメインの課題を解決する部分を表すとありました。
しかし、私はシステムを「チームやシステムごとに独立して意味を持つ領域に分割」することで、複雑さを管理しやすくする考え方と説明する方が適切であると思います。
DDDにおける「コンテキスト」とは、いわば「企業や組織の文化」のような意味を持ちます。
part1で説明したように、DDDでは「ユビキタス言語」を用いて実装します。そこで、ユビキタス言語の意味が変わる境界で「境界づけられたコンテキスト」を用いよう！ということです。そんなことをして何がいいのかというと、異なる概念が混ざらないため、比較的シンプルなものが作れるということです。
おわりに
今回は「ドメイン」や「境界づけられたコンテキスト」などについて解説しました。新しい考え方に混乱する方も（私を含め）いると思いますが、自分なりに落とし込んで理解できるよう頑張りましょう！
また次回もよろしくお願いします。