业务流程“传递”一对多的关联。
领域简介
我有个推销员。一个推销员得到了商业机会的机会。在我的领域，这两者都是有意义的。
有两种方法可以对此进行建模：
- 推销员总人数不知道其业务机会，或
- 推销员知道他的机会清单(当然是使用OpportunityId )。
我相信，BusinessOpportunity总是需要知道它的SalesmanId。
问题
我有一个使用process模式实现的业务流程。这是一个"TransferAllBusinessOpportunities“过程。这意味着需要一个推销员，并将他/她所有的机会“转移”给另一个人。
我们该怎么做？我们应该如何对域进行建模？
如果我们将它建模为一个双向关联，那么我可以想到一个进程状态机，但它非常复杂。如果我们只有单向关联的话，我不知道该如何做，因为我们需要求助于read模式来获得要转移的商业机会列表，我担心我们应该把所有的东西都保存在写端模型中。你对此有什么看法？
任何帮助都是非常感谢的。下面附上一个图表，以帮助可视化，如果这有帮助。
这些问题的快速综合：
- 你会如何处理这个问题？
- 您将如何建模域，以最好地解决这一问题？
- 可以在命令处理程序中使用read模型来执行业务流程吗？
再次感谢。
回答 1
Stack Overflow用户
发布于 2016-03-30 19:57:48
元答案:你需要阅读格雷格杨对集验证的看法。您将能够更好地与您的领域专家一起探索您的需求。
如果我们只有单向关联，我不知道该如何做，因为我们需要求助于read模型来获得商业机会列表
从读取模型中提取数据应该是您的第一选择。有什么问题吗？
基本轮廓
- 查询集合的读取模型
- 创建命令来更新基于集合的写入模型
- 将命令分派给写模型
- 写模型从命令(而不是从读取模型)获取它所需的集合数据。
第一步并不总是满足您的需求，但它是思考用例的一个很好的起点。如果您实现这个简单的方法，会发生什么问题？这些问题会给企业带来什么损失？
还有:我说了上边推荐，但可能不是。您没有描述的一件事是模型的哪一部分“决定”了转移。模型是否允许拒绝传递机会的命令？在什么情况下？哪个聚合保存确定是否允许传输的状态？
它可能不是一个命令，而是一个事件，描述了某个销售经理所做的决定。
我担心我们应该把一切都保留在书面模型中。
也许吧。是否有业务不变式需要集合的状态？到目前为止，它听起来并不像它，这强烈地意味着集合不属于写模型。您希望尽可能地减少聚合，同时又不丧失强制执行不变的能力。
可以在命令处理程序中使用read模型来执行业务流程吗？
是"ok“吗？从我在不同地方读到的资料来看，很多人都这么认为。就我个人而言，我不相信。大致上，你看的是两个大致的轮廓。
- 创建一个瘦命令
- 将命令发送到命令处理程序
- 查询读取模型以充实缺失的详细信息
- 处理已充实的命令
vs
- 查询读取模型
- 使用查询结果构造fat命令
- 将命令发送到命令处理程序
- 处理命令
我还没有看到一个业务会关心这两个实现之间的区别的例子；后者的实现更容易预测(您不需要知道任何有关读取模型的状态、聚合状态和命令状态的信息)。
https://stackoverflow.com/questions/36321823
复制相似问题
腾讯云开发者
