dom*_*min 9 workflow domain-driven-design business-process-management hexagonal-architecture
一些消息来源声称流程管理器不包含任何业务逻辑。例如，微软的一篇文章是这样说的：
\n\n\n您不应使用流程管理器在您的域中实现任何业务逻辑。业务逻辑属于聚合类型。
\n
再往上他们还这么说（强调我的）：
\n\n\n需要注意的是，流程管理器不执行任何业务逻辑。它仅路由消息，并且在某些情况下在消息类型之间进行转换。
\n
但是，我不明白为什么消息之间的转换（例如从域事件到命令）不是业务逻辑的一部分。您需要领域专家才能知道正确的步骤顺序以及步骤之间的转换。在某些情况下，您还需要在步骤之间保留状态，甚至可能根据某些（业务）条件选择后续步骤。因此，并非所有内容都是给定步骤的静态列表（尽管我\xe2\x80\x99d 也调用业务逻辑）。
\n在我看来，在很多方面，流程管理器（或就此而言的传奇）只是另一种持久状态的聚合类型，并且可能具有一些业务不变量。
\n假设我们用六边形架构实现 DDD，I\xe2\x80\x98d 将进程管理器放置在应用程序层（不是适配器！！），以便它可以对消息做出反应或由计时器触发。它将通过存储库加载相应的流程管理器聚合，并调用其上的方法来设置其（业务）状态或要求其发送下一个命令（当然，实际发送是由应用程序层完成的）。该聚合位于领域层，因为它负责业务逻辑。
\n我真的不明白为什么人们要区分业务规则和工作流规则。如果删除除领域层之外的所有内容，您应该能够重建工作应用程序，而无需再次咨询领域专家。
\n我\xe2\x80\x98d 很高兴从你们那里得到一些我可能缺少的进一步见解。
\n领域逻辑不仅存在于聚合和领域服务中。其他地方有：
\n在我看来，这三件事被 \xe2\x80\x93 误认为是仅应用程序层的问题的原因如下：
\n最后说一下耦合。在我看来，社区中有一种趋势，即耦合本身就是一件坏事，因此必须通过一切手段避免/减轻。这可能会导致诸如将事件命令翻译（记住：域逻辑！）放在六边形/洋葱/干净架构的适配器层中之类的解决方案。该层的职责是将某些东西适应具有相同语义/功能但形式略有不同的其他东西（想想电源适配器）。它不是托管任何类型的域逻辑的地方，即使它非常简单。企业到处都有依赖性和耦合性。艺术就是在它实际所在的地方拥抱它，否则就避免它。我们在 DDD 中建立合作伙伴关系或客户/供应商关系是有原因的。如果我们关心域逻辑隔离，那么这些依赖关系就会反映在它们所属的位置：在域层中。
\n