たなかこういちの開発ノート

システム開発に携わる筆者が、あれこれアウトプットするブログ

私的実践DDD、その3

(※前回からの続きです。)
 
「境界付けられたコンテキスト」は常に理想形を、「サブドメイン」はその時の現実を表す
 
まず確認すると、「リポジトリー」や「集約」はシステムの設計・構築レベルの話でしたが、「境界付けられたコンテキスト」や「サブドメイン」は、業務分析レベルの話をしています。個々の実装物をそれぞれ如何に実装あるいは設計するかというよりも、複数の実装物の機能スコープをどのように分割し管理するか、と言った観点の話です。
 
「境界付けられたコンテキスト」と「サブドメイン」の関係について、「実践ドメイン駆動設計」の2章10節にて「各サブドメインを 、境界づけられたコンテキストと一対一で対応させるのが 、望ましいゴ ールだ 。」言っています。少なくとも目指すべき姿としては、「境界付けられたコンテキスト」と「サブドメイン」は同一のものを指している/指そうとしている、と理解できます。しかし、現実は必ずしもそのように理想的ではない。そのとき、“あくまで理想的なサブドメイン分割”を「境界付けられたコンテキスト」と称し、現実の実際のサブシステムの分割の有り様を「サブドメイン」と言っていると解されます。
 
つまり、AS-IS構成を「サブドメイン」構成として認識し、理想形としての「境界付けられたコンテキスト」を念頭にTO-BE構成を描く、という作業になります。TO-BEもまた、DDDを適用できないサブシステムが存在するなどの理由から、常に理想的に「境界付けられたコンテキスト」と一対一対応した「サブドメイン」をデザインできるものでは無いかもしれません。それでも「境界付けられたコンテキスト」と「コンテキスト・マップ」は目指すべき地平としてメンテし続けるのです。
 
境界付けられたコンテキストの内側はnominal typing、腐敗防止層とはstructural typingによって依存性を断ち切るI/F
 
境界付けられたコンテキストとは、特定の語彙セット=ユビキタス言語、が通用する境界線でもあります。境界付けられたコンテキスト=特定の語彙セットの通用する空間域=サブドメインの認識=実装物としてのサブシステム、これらが全て一対一対一対一対応であるのが理想形、ということになります。
 
特定の語彙セットが通用する空間域、とは、型システム的理解では、nominal typingな型セットを共有できる空間域、と言えるでしょう。というよりも、境界付けられたコンテキストを越えてはnominal typingで処理できない/すべきでない、と捉えるべき、ということです。コンテキスト・マップにて腐敗防止層の向こう側のコンテキストで定義されている語彙セット=型セットを、こちら側のコンテキストでそのまま使うわけにはいきません。DDDでは第三者の“名前空間”をimportすることは推奨されていません。腐敗防止層とは、相手先コンテキストが定義する型に侵食されないように、相手先への依存性を断ち切るために、structural typingでのI/Fを設けたもの、と捉えて間違いは無い(はず)です。
 
「実践ドメイン駆動設計」では、腐敗防止層の説明でJSONデータをパースするようなExampleを示していますが、このような外部表現のパース処理とは、型システム的にstructural subtypingでデータを受け入れている様子と、趣旨的にトポロジー的に同義、と解釈できるものと考えます。
 
◆以上
(※次回へ続きます。)