HATEOAS REST API和领域驱动设计，工作流逻辑放在哪里？

Question

每个域对象包含与特定有界上下文(X)中的特定对象相关联的业务逻辑。REST API包含将查询或命令的结果转换为通过网络发送的数据（例如JSON）的逻辑。当使用HATEOAS和超媒体时，我们希望使用链接来建模资源之间的关系。但是，为了确定REST API应该返回哪些链接，通常需要求助于业务逻辑/规则。问题是，这些“工作流规则”在DDD应用程序中属于哪里？它们可能在一个不同的有界上下文中只处理工作流规则（可能在与X的类似“伙伴”的关系中），还是属于X BC？

Answer 1

我不是DDD专家（仅通过Eric Evan的书中的100页），但我可以告诉你在我们的电子商务目录中发生了什么。

最初，我们基于数据和请求用户的角色/权限，在应用程序的相同有界上下文中有这样的业务流，我们改变了呈现给用户的状态转换（您说的是链接，但这实际上是它的核心，链接只是呈现状态转换的一种方式）。这工作正常，但执行了大量重复的逻辑。然后，我们添加了一个搜索应用程序，它是一个不同的有界上下文，因为它显示了相同的数据，但在不同的集合/分组中，我们不希望它们不同步。

我们转到了CQRS实现，因此我们的许多业务逻辑是“预先计算”的，因此它类似于“合作伙伴上下文”，作为我们从写模型到读模型的投影的一部分。我们不专门存储链接，而是在数据上标记允许的行为。catalog应用程序和search应用程序都使用这个读模型和它的行为标志来确定要呈现给客户端的状态转换。