"Transfer" 一对多关联的业务流程
Business Process to "Transfer" a one-to-many association
域简介
我有一个推销员。推销员获得商业机会。在我的领域中，两者都可以成为 AR。
有两种建模方法：
- 销售员聚合体没有意识到它的商机，或者
- 销售员知道他的机会列表（当然使用 OpportunityId）
我相信，BusinessOpportunity 总是需要知道它的 SalesmanId。
问题
我有一个业务流程，我计划使用流程管理器模式来实施。这是一个 "TransferAllBusinessOpportunities" 过程。这意味着将 1 名销售员和 "transferring" 所有 his/her 机会交给另一个。
我们应该怎么做？我们应该如何为域建模？
如果我们将其建模为双向关联，我可以想到一个进程状态机，但它非常复杂。如果我们只有单向关联，我不知道该怎么做，因为我们需要求助于读取模型来获取要转移的业务机会列表，我担心我们应该将所有内容都保留在写入中边模型。你怎么看？
非常感谢任何帮助。如果有帮助，请在下面附上一张图表以帮助形象化。
问题的快速总结：
- 你会如何解决这个问题？
- 您将如何为域建模以最好地解决这个问题？
- 可以在命令处理程序中使用读取模型来执行业务流程吗？
再次感谢。
元答案：您需要阅读 Greg Young 对 set validation 的看法。您将能够更好地与您的领域专家探讨您的需求。
I don't know how to do it if we only have a unidirectional association because we'd then need to resort to the read model to get the list of business opportunities
从读取模型中提取数据应该是您的首选。有什么问题？
基本大纲
- 查询集合的读取模型
- 创建命令以根据集合更新写入模型
- 将命令分派给写入模型
- 写入模型从命令中获取它需要的设置数据（不是来自读取模型）
第一种方法不一定总能满足您的要求，但它是考虑用例的良好起点。如果您实施这种简单的方法，会出现什么问题？这些问题会给企业带来什么损失？
另外：上面说了表扬，也不一定。您没有描述的一件事是模型的哪一部分 "decides" 传输。是否允许模型拒绝转移机会的命令？在什么情况下？哪个聚合包含确定是否允许传输的状态？
转移可能没有被描述为命令，而更像是一个事件，描述了某个人类销售经理做出的决定。
I'm worried that we should keep everything in the write-side model
也许吧。是否存在需要集合状态的业务不变量？到目前为止，听起来不像，这强烈暗示该集合不属于写入模型。您希望在不失去执行不变量的能力的情况下尽可能地减少聚合。
Is it ok to use the read model in a command handler to execute the business process?
是"ok"吗？从我在各个地方看到的来看，有不少人是这么认为的。就个人而言，我不相信。粗略地说，您正在查看两个大纲
- 创建瘦命令
- 将命令发送到命令处理程序
- 查询读取模型以充实缺失的细节
- 处理充实的命令
对
- 查询读取模型
- 使用查询结果构造胖命令
- 将命令发送到命令处理程序
- 处理命令
我还没有看到业务会关心这两种实现之间的区别的示例；后一种实现更容易预测（你不需要知道任何关于读取模型的状态，只需要聚合的状态和命令的状态）。
域简介
我有一个推销员。推销员获得商业机会。在我的领域中，两者都可以成为 AR。
有两种建模方法：
- 销售员聚合体没有意识到它的商机，或者
- 销售员知道他的机会列表（当然使用 OpportunityId）
我相信，BusinessOpportunity 总是需要知道它的 SalesmanId。
问题
我有一个业务流程，我计划使用流程管理器模式来实施。这是一个 "TransferAllBusinessOpportunities" 过程。这意味着将 1 名销售员和 "transferring" 所有 his/her 机会交给另一个。
我们应该怎么做？我们应该如何为域建模？
如果我们将其建模为双向关联，我可以想到一个进程状态机，但它非常复杂。如果我们只有单向关联，我不知道该怎么做，因为我们需要求助于读取模型来获取要转移的业务机会列表，我担心我们应该将所有内容都保留在写入中边模型。你怎么看？
非常感谢任何帮助。如果有帮助，请在下面附上一张图表以帮助形象化。
问题的快速总结：
- 你会如何解决这个问题？
- 您将如何为域建模以最好地解决这个问题？
- 可以在命令处理程序中使用读取模型来执行业务流程吗？
再次感谢。
元答案：您需要阅读 Greg Young 对 set validation 的看法。您将能够更好地与您的领域专家探讨您的需求。
I don't know how to do it if we only have a unidirectional association because we'd then need to resort to the read model to get the list of business opportunities
从读取模型中提取数据应该是您的首选。有什么问题？
基本大纲
- 查询集合的读取模型
- 创建命令以根据集合更新写入模型
- 将命令分派给写入模型
- 写入模型从命令中获取它需要的设置数据（不是来自读取模型）
第一种方法不一定总能满足您的要求，但它是考虑用例的良好起点。如果您实施这种简单的方法，会出现什么问题？这些问题会给企业带来什么损失？
另外：上面说了表扬，也不一定。您没有描述的一件事是模型的哪一部分 "decides" 传输。是否允许模型拒绝转移机会的命令？在什么情况下？哪个聚合包含确定是否允许传输的状态？
转移可能没有被描述为命令，而更像是一个事件，描述了某个人类销售经理做出的决定。
I'm worried that we should keep everything in the write-side model
也许吧。是否存在需要集合状态的业务不变量？到目前为止，听起来不像，这强烈暗示该集合不属于写入模型。您希望在不失去执行不变量的能力的情况下尽可能地减少聚合。
Is it ok to use the read model in a command handler to execute the business process?
是"ok"吗？从我在各个地方看到的来看，有不少人是这么认为的。就个人而言，我不相信。粗略地说，您正在查看两个大纲
- 创建瘦命令
- 将命令发送到命令处理程序
- 查询读取模型以充实缺失的细节
- 处理充实的命令
对
- 查询读取模型
- 使用查询结果构造胖命令
- 将命令发送到命令处理程序
- 处理命令
我还没有看到业务会关心这两种实现之间的区别的示例；后一种实现更容易预测（你不需要知道任何关于读取模型的状态，只需要聚合的状态和命令的状态）。