有个项目 业务逻辑大致是这样的。 项目主体是委托单 可以按业务需求不同。委托不同的业务服务。
委托单和各种不同的业务服务单据都是实体对象。
看起来委托单是聚合根，
因为所有其他业务单据的执行情况都会影响和反馈到委托单上来。
委托单的领域模型聚合的里面包含这些个服务单据的实体？
而各种业务服务单据从各自的角度上看也可算作聚合根 ，他们要处理很多复杂具体的业务并且相互不影响（说相互之间不影响 是因为部分服务即使失败 整个委托单也未必终止....）。
由于网上大大们举例都比较简单易懂。 碰上具体业务 小弟有点发懵~
这种情况领域模型应该怎么建立？ 委托单建一个 各自服务个建一个？
还是说 只有委托单是唯一的聚合根？
从目前你提供的信息来看，委托单可能是唯一聚合根，业务服务是一种领域服务，而不是实体。
当然我们不知道委托单委托的是什么具体实体。其实单据本身不是实体，只不过是一个管理方式反映，如同“桌子”词语和桌子这个事物其实两回事。所以，我们建模不是将实际手工方式原封不动照搬照抄到电脑流程中，而是分析需求的本质规律。委托单可能只是我们软件的一个输出打印的表单而已。
您好， 大体业务是这样
委托单
委托服务A（办理银行手续相关信息） 委托服务B（办理政府部门手续相关信息） 还有CDEF 等等等等。
委托项目客户自选。 可能是A 可能是B 可能是ABCDEF...
委托单本身有生命周期 “服务”的结果也能影响和反馈到委托单上。个人感觉上这已经形成了聚合。 而根就是委托单本身。
“服务”本身也有生命周期，有各自的内部规则 “服务”与“服务”相互之间基本独立（一俩个服务做砸了 或者客户取消了部分委托。但可能其他被委托的服务依然需要执行下去）。 感觉每个“服务”又是个小聚合。
-----------------------------------------
从我目前的理解来看， 这变成了某个领域模型里面的”实体“又是其他领域模型中的”实体“而且还是聚合根？（由于这个项目只牵扯到 人 服务 单据。 我实在不知道 那些个”服务“ 该如何称呼他们。暂时称作了实体。）
如果把”服务“们 单纯看成领域服务。 那这个领域模型个人感觉 太过庞大和复杂了。 委托服务目前就接近20种 公司业务扩展的话... 而且每种委托服务需要记录和跟踪的信息又很多。