Domain driven design 将业务流程更改为“；“转让”；一对多协会

领域介绍

我有一个推销员。推销员得到商机。在我的领域里，这两者都是有意义的

有两种方法对此进行建模：

销售人员不知道其业务机会，或

销售人员知道他的机会列表（当然使用OpportunityId）

我相信，一个商机总是需要知道它的推销员

问题

我计划使用process Manager模式实现一个业务流程。这是一个“转移所有商机”的过程。这意味着抓住一个销售人员，并将他/她的所有机会“转移”给另一个销售人员

我们应该怎么做？我们应该如何对域进行建模

如果我们将其建模为一个双向关联，我可以想到一个进程状态机，但它相当复杂。如果我们只有单向关联，我不知道该怎么做，因为我们需要借助读模型来获取要转移的商业机会列表，我担心我们应该将所有内容都保留在写端模型中。你觉得怎么样

非常感谢您的帮助。如果有帮助，请在下面附上一张图表以帮助可视化

问题的快速总结：

你将如何解决这个问题

您将如何对域进行建模以最好地解决此问题

在命令处理程序中使用read模型来执行业务流程可以吗

---

再次感谢。

元答案：你需要读一下格雷格·杨的话。您将能够更好地与领域专家探讨您的需求

如果我们只有单向关联，我不知道该怎么做，因为我们需要借助read模型来获得商业机会列表

从读取模型中提取数据应该是您的第一选择。有什么问题吗

基本轮廓

查询集合的读取模型

Create命令根据集合更新写入模型

将命令分派到写入模型

• 写入模型从命令（而不是读取模型）获取所需的集合数据

第一种方法并不总是满足您的需求，但它是思考用例的一个良好起点。如果用这种简单的方法实现，会出现什么问题？这些问题会让企业付出什么代价

还有：我在上面说了赞扬，但可能不是。您没有描述的一件事是模型的哪一部分“决定”了转移。是否允许模型拒绝转移商机的命令？在什么情况下？哪个聚合持有确定是否允许传输的状态

这可能是因为传输不是被描述为一个命令，而是被描述为一个事件，描述了某个销售经理做出的决策

我担心我们应该将所有内容都保留在写端模型中

也许吧。是否存在需要集合状态的业务不变量？到目前为止，它听起来不像，这强烈地暗示了集合不属于写模型。您希望在不丧失强制执行不变量的能力的情况下尽可能地剥离聚合

在命令处理程序中使用read模型来执行业务流程可以吗

“行”吗？从我在各地看到的情况来看，很多人都这么认为。就我个人而言，我不相信。大致上，您将看到两个大致轮廓

创建精简命令

将命令发送到命令处理程序

查询读取模型以充实缺少的细节

处理充实的命令

vs

查询读取模型

使用查询结果构造fat命令

将命令发送到命令处理程序

处理命令

---

我还没有看到一个企业关心这两种实现之间区别的例子；后一种实现更容易预测（您不需要知道任何关于读取模型的状态，只需要知道聚合的状态和命令的状态）

谢谢@VoiceOfUnreason这很有见地。在一个命令处理程序中对多个bo-ar执行$repository->save（$bo）可以吗？我一直试图保持它的简单性，每个命令处理程序只执行一个AR/事务。在一个命令处理程序中查询读取模型并循环所有BO会很方便，并将每个BO持久化。否则，我会做大量的消息传递/倾听来处理业务流程（无论如何，这都在同一个BC中）。想法？“您觉得在一个命令处理程序中对多个bo执行$repository->save（$bo）可以吗？”不——如果引入的争用是可接受的，为什么这些东西是单独聚合的？当我查询读取模型时，我会得到一个列表，例如，20个BusinessOpportunityID。这些需要被传输，所以我可以做一个fat命令，上面写着“传输（BoList，othersaller）”，这将需要对每个单独的聚合进行20次更新。或者我应该发出20个命令，每个命令有一个AR？i、 例如，“transfer（BO，othersaller）”x20？对负责执行不变量的每个聚合执行一个命令。否则，您会遇到一个（或多个）BusinessOpportunities拒绝转移的问题（这真的很可疑——这个问题/问题是否试图向您暗示您的域模型是错误的？）