本記事は、ドメイン駆動設計#1 Advent Calendar 2019の9日目です。
本日はIDDDの戦略的設計についての記事です。
導入
DDDを勉強する場合DDD本、IDDD本で勉強するのが多いのではと思います。
内容難しいですよね。本厚いですし。
最近IDDDを読み直しており、以前躓いていたIDDDの戦略的設計について少しだけ理解度が上がったと思いました。
そこで私がIDDDを読む上で引っかかっていた部分や、最近理解が向上した箇所について共有します。
DDDにおける2つの設計
1.2 あなたがDDDをすべき理由 より
DDDは、戦略的設計と戦術的設計の両面で、健全なソフトウェア開発技術を提供する。
とあるように、DDDでは戦略的設計、戦術的設計の2つの設計が語られ、
IDDDでは2,3章で戦略的設計、4章~14章で戦術的設計について語られております。
戦略的設計・戦術的設計がなにか。
はググれば色々わかりやすい記事が出てくるので詳細は省きますが、
戦略的設計
何を作るか。を明確化するための設計手法戦術的設計
どのように作るか。の設計手法
のような関係性だと思っております。
なお、戦略的設計をせずに戦術的設計のみを適用したDDDは「軽量DDD」と呼ばれます。
IDDDによる戦略的設計の理解で詰まった2つのポイント
ドメイン、サブドメイン、境界づけられたコンテキストの関係性
一気にいろいろな言葉がでてきますね。
ドメイン、コアドメイン、サブドメイン、境界づけられたコンテキスト…
いろいろな概念がたくさん出てくるので理解するのが大変そうだと思い、
まず図からそれぞれの関係性を理解しようと思ったのですが、
こんな感じの図(図2-1 ドメインとサブドメインそして境界づけられたコンテキスト)が出てきて、ますます混乱してしまいますよね。
関係性がぐちゃぐちゃに見えます。
結局、境界づけられたコンテキストとドメインはどういった関係になるのだと。
エヴァンスさんのDDDでは
境界づけられたコンテキスト ⊇ モデル ⊇ サブドメイン
の順に抱合関係にあり、わかりやすかったのですが、これは一体なんなんですかね…
図の意味
IDDD 2章は基本的に仮想のプロジェクトにDDDを適用していくストーリーで構築されております。
DDDを導入していない/導入に失敗したような既存システムなどではサブドメインと境界づけられたコンテキストが一致していないことが多く、仮想プロジェクトも軽量DDDを取り入れたことによりサブドメインと境界づけられたコンテキストが一致しなくなってしまっております。
そのようなシステムにおいて、新たにコアドメインを作成していく例をあげているため、上の図は、あえてそのサブドメインと境界づけられたコンテキストが一致していない状態を表しているのですね。
結局
IDDD内で著者は
各サブドメインを、境界づけられたコンテキストと一対一で対応させるのが、望ましいゴールだ。
と言及しております。
望ましいゴールにたどり着けたとしたら、それぞれのサブドメイン（破線）とコンテキスト（実戦）が一致する。
ということでしょうかね。
問題空間・解決空間とシステムの関係性
ドメインは、問題空間と解決空間を持っている。
と記述がありますよね。
それぞれ、
問題空間
解決すべきビジネス戦略上の課題を浮き彫りにするもの。ドメインの一部解決空間
ソフトウェアをどのように実装してその課題を解決するかに注目するもの。境界づけられたコンテキストのこと
と説明されておりますが、最初読んだときは関係性があまりわからなかったものです。
問題空間と解決空間の関係性は以下の図により理解がすすみました。
この図も実戦が境界づけられたコンテキスト、破線がサブドメインを表しております。
ERPと、マッピングコンテキストといったシステムを境界づけられたコンテキスト（=解決空間）としているため、
解決空間とは、システム（既存システム、これから作るシステム）と理解できそうです。
そして図の説明文として
図2-4 在庫と購買に関わる、コアドメインとその他のサブドメイン。問題空間の分析に使うサブドメインだけに絞ったものであり、ドメイン全体を表しているものではない
とあるように、図全体が問題空間（=コアドメインを生み出すための開発を要するところ）のということになりそうです。
仮想プロジェクトのように、既存システムにDDDを適用していく場合は、上述の通り境界づけられたコンテキスト = サブドメイン とは必ずしもならないため問題空間と解決空間に抱合関係は生まれなさそうです。
ただ、新規にDDDで構築していく場合は、問題空間からコアドメイン（=解決空間）を生み出すとして、問題空間 ⊇ 解決空間 の関係性を意識できそうです。
まとめ
きちんと文章を読めばそんなに引っかかるものでもなかったところですが、もしかしたら私のように図にイメージを引っ張られてそれぞれの関係性がごちゃごちゃになってしまった方もいるのではないかと思います。
なぜ戦略的設計を取り上げたか
IDDDの最初のほうだったから
過去のPJで軽量DDDを経験し辛いこと（オブジェクトの肥大化や似たようなオブジェクトの乱立）もあったためしっかり戦略的設計も学ぼう。と思ってました。
経験上こんなことがあったら危険だと判断しています
自分たちでクラス名を考える
実装中にクラス名をこじつけのように考えだしたら黄色信号かもしれません。
業務を分析できていれば業務で使われる言葉がもしからしたらあるかもしれません。似てるけど微妙に違い"そう"なモデルがある。
なぜ同じクラスか（またはなぜ別のクラスか）を言葉にできない状態は赤に近い黄色だと思います。
もしかしたら異なる境界づけられたコンテキスト内に所属するユビキタス言語の可能性があります。
最後に
それぞれの概念の抱合関係が理解できると読みやすくなると思っております、
戦略的設計のそれぞれの概念の関係性の理解に役立てば幸いです。