Subdomainに分解する
一度、Domain EventやDDDのCommandに着目して大きな流れを掴んだ後に、いくつかのSubdomainに分解する
Aggredateよりも大きな粒度
各Subdomainは明確な責務を持つ
Domainを小さく作る
疎結合
修正容易
そのdomainに集中できる
整理しやす
流れを時系列に分けているわけではない
大雑把なEntityというか、それこそSubdomainに分解している
例えば、ECシステムであれば、大きな流れを以下の3つに分解できる
注文
発送
請求
大まかな流れ
Domain EventやDDDのCommandに着目して大きな流れを掴む
これを参考に、いくつかのSubdomainに分解する
この時点では問題領域の話をしており、各Subdomainが重なる部分があるかもしれない
これを、解決領域にマッピングする
この際に、Bounded Contextを意識して、各Subdomainが互いに重ならないようにする
重ならないようにするのは、疎結合にし、依存を小さくするため
問題領域→解決領域にマッピングが常に1対1にできるわけではない
各Subomainに優先順位を付ける
Core Domain
ビジネスやお金に直撃する重要なDomain
Supportive Domain
Core Domain以外のDomain
特に、そのビジネス固有でないものをGenereic Domainと呼ぶ
実装時に、外注しても良い
/mrsekut-book-97816805025/035 ~
billling domainですらもCoreじゃないんだmrsekut.icon
『エリック・エヴァンスのドメイン駆動設計』.iconでは、Bounded Contextが必要になる時ってシステムがかなり大きいことが前提されている感じがある
一方で、『Domain Modeling Made Functional』.iconではそこまで大きいシステムでなくても、分けることが有用であるという主張
参考
/mrsekut-book-97816805025/029~