戦略的DDDについてまとめる

概要

この記事はDDD（ドメイン駆動開発）のうち戦略的DDDについて説明したものになります。
バックエンドエンジニアとして働いていたときに得た知見をまとめてみました。

最終目的

DDD（に限らずですが）の最終目標は利益を出せるシステムを作ることです。（これは営利企業においての話です）
もちろん経営理念を達成とかでもいいですが、それを計測する指標は利益などになるはずです。

エンジニアとしての目的

とはいえ、エンジニアとしての目的に利益を置くのは難しいです。（コーディングやPRのマージでは直接的に金銭は得られないですし）
そこで、DDDでは「ビジネスモデルの変化に追従する」ことを目的にします。
利益をだせるビジネスモデルは世の中にあわせて変化していくものです。
ビジネスモデルの変化に追従することは利益を出し続けることにつながるはず、という仮定に沿ってシステムを設計することがDDDの基本的な理念になります。

DDDには大きく分けて戦略的DDDと戦術的DDDの2段階あります。
戦略的DDDはウォーターフォールでいえば要件定義～基本設計あたりになり、戦術的DDDは基本設計～実装あたりになります。
この記事は戦略的DDDについてまとめたものになります。

手段

ビジネスモデルの変化に追従するには、システムの構成がビジネスモデルと同じ形になっていることが一番確実です。
以下のような手順でこれを達成していきます。

• ドメインエキスパートとのコミュニケーションを密に取る
• ドメインモデルを作成する
• ユースケースを洗い出す

ドメインエキスパートとのコミュニケーション

ドメインエキスパートとはそのビジネスモデルについての知識が豊富な人のことです。
ビジネスモデルを理解するには、ドメインエキスパートとのコミュニケーションでは認識の齟齬をなくすことが重要になります。

とはいえ、職種が違う人間同士がコミュニケーションを取る以上、なんとなくで会話してるとどうしても認識の齟齬がでてくるでしょう。
そのため、ビジネスモデルにでてくる用語の意味をはっきりと定義、共有することが重要になります。
この用語集をユビキタス言語といいます。ユビキタス言語を使って会話することで、ビジネスモデルへの理解が深まり円滑なコミュニケーションが取れるようになるはずです。

ドメインモデルを作成する

ユビキタス言語によるコミュニケーションをもとに、ドメインエキスパートの頭の中にあるビジネスモデルを可視化します。
これをドメインモデルなどと呼び、ドメインモデルやドメインモデル間の関係性などを表現したものをコンテキストマップといいます。

これは私見ですが、ドメインモデルとは「紙と鉛筆だけの運用になってもなお残るもの」と言えると思います。
例えば、AmazonのようなECサイトは百貨店をデジタル化したもので、紙と鉛筆だけになっても以下のようなものは残るはずです。

• 商品
  • 商品名
  • 価格
  • 在庫
• 顧客
• etc

これは極端な例ですが、ここで重要なのはドメインモデル（ビジネスモデル）はデバイス（紙/鉛筆、ブラウザ、モバイル、DBなど）に依存しないということです。

ユースケースを洗い出す

ドメインモデルを作成したら、そのモデルを使ってユースケースを洗い出します。
上のECサイトの例でいえば、商品の購入などがユースケースになります。
ユースケースは基本的にユースケース図をなぞった手続き的なものになるはずです。
ユースケースはドメインモデルに依存しますが、デバイスに依存しないものになります。

境界付けられたコンテキスト

小規模なビジネスモデルであれば上記の手法で十分だと思いますが、ある程度規模が大きくなると複数のビジネスモデルが絡み合ってくることがあります。
ECサイトの例でいえば、商品購入と配送管理は別のビジネスモデルとして考えてもいいでしょう。

このような場合、ビジネスモデルを境界付けられたコンテキストとして分けることを検討するのもいいでしょう。
境界付けられたコンテキストに沿ってビジネスモデルごとにモジュール分割することで、大きな1つのシステムよりも保守性が高くなりやすいです。
モジュール分割の際には、モジュラーモノリスやマイクロサービスなどのアーキテクチャを検討してもいいと思います。

クリーンアーキテクチャの導入

上記の手法で見たように、ビジネスモデルは大きく3つの層に分かれます。

• ドメインモデル
• ユースケース
• 入出力デバイス

ということは、システムもこのような層に分かれていたほうが設計しやすくなるでしょう。
そのため、クリーンアーキテクチャ（に類するレイヤードアーキテクチャ）を導入して、層の区切りや依存関係をコントロールします。

おわりに

戦略的DDDについてざっくりまとめてみました。
まぁ、結局のところ一番難しいのはドメインエキスパートと会話（できるような環境、チーム体制を構築）することだと思います...