ドメイン駆動設計実践編 ～全体像～

どうも、畜産ペンギンです。

 

交流戦ですが、今年はパリーグが例年程怖くないですね。

コロナ下という事もありドサクサに紛れてカオスなシーズンになりそうです。

 

今回は前回概要を説明したドメイン駆動設計の実践編です。

ですがまぁ言ってる事がかなり複雑というか言い方がややこしい事が多いので今回も概念的な話が多くなります。

 

前回の内容はコチラ→「ドメイン駆動設計について。」

※用語についていくらかは前回の内容を理解してる前提で書いて行きます。

 

目次は以下の通り。

 

目次

・ドメイン駆動設計の全体図 ・境界づけられたコンテキストとは ・ユビキタス言語とは ・まとめ

 

ドメイン駆動設計の全体図

いきなりですがよくある小売業のドメイン、サブドメイン及び境界づけられたコンテキストを図に表すと以下のような感じになります。

 

 

青が全体のドメイン、橙が境界づけられたコンテキスト、黄緑がサブドメインとなります。

 

サブドメインというのはその名の通りドメインの中で分割されたドメインとなりなんとなくわかると思いますが

境界づけられたコンテキストというのはイメージ沸き辛いですよね。

 

「境界づけられたコンテキスト」と更に「ユビキタス言語」というのがドメイン駆動設計を理解する上で非常に重要なキーワードなので後述で説明します。

 

境界づけられたコンテキストとは

簡単に説明しますとドメインが「問題領域」ならコンテキストが「解決領域」、そしてどこを境界に置くかというと「特定のモデルを定義・適用する範囲」となります。

※モデルの概念については前回いくらか説明してます。

 

実際に形として現れる代表例としては上の図の通りサブシステム等が当てはまります。

 

ドメイン駆動設計の本来あるべき姿としては1つのモデルに対して1つの境界づけられたコンテキストが紐づけられるがベターと考えられていると思います。

 

なぜなら複数のモデルに1つの境界づけられたコンテキストを紐づけるとモデルに変更が入る際、影響範囲が他のモデルまで波及してしまう恐れがあるからです。

まぁオブジェクト指向的な考えですね。

 

そういう意味では上の図のECシステムはドメイン駆動設計の考えに反していると言えるでしょう。

まぁ論理的に一つのサブシステムを更に分割して考えれば1対1に考えれる等はあるでしょうがややこしいので省略。

 

また、後述する「ユビキタス言語」が通じる範囲とするべきとしています。

 

ユビキタス言語とは

簡潔に言うと境界づけられたコンテキスト内で作り上げる共有言語となります。

 

よく勘違いされる例として、プロジェクトや業界での標準として定められている用語の事と思われるらしいですが違います。

 

モデルを基準に考えるとわかりやすいと思います。

例えば商品をモデル化する際、人によって「形」「色」「価格」等、人によって思い浮かべる物は違うと思いますが

これをドメインによって最適化して共有したものがユビキタス言語の一例に当てはまります。

 

また、境界づけられたコンテキスト、ユビキタス言語は1対1で紐づけられる状態が望ましいとされています。

もっと言うと、モデルと境界づけられたコンテキストは1対1にするのが望ましいのでモデルとユビキタス言語が1対1にするのが望ましいとも言えます。

 

例えばですが、小売業ですと商品に対してもモデルを形作るのに必要な情報は異なります。

商品カタログサブドメインのモデルですと「価格」等が必要ですが、発送サブドメインのモデルでは「発送先」等が必要になってきます。

 

これらを全て併せてシステム全体で商品という物に対して共通のモデルを持とうとすると非常に複雑なモデルになってしまいます。

ですのでモデル、境界づけられたコンテキスト、ユビキタス言語は一定同じ単位で分割する必要があるという事ですね。

 

まとめ

前回はドメイン駆動設計は問題解決に注視したアプローチという話をしましたが、今回は問題や解決法をどう分割していくかという話になりましたかね。

 

次回はどっから切り込むか正直決めかねてますが結局ドメインとモデルが核となるのでそこを突き詰める方向に進めればと思います。

 

今回はここまでです。

 

さようなら。