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

Question

这是RESTful API的后续问题:我应该在哪里编写工作流程？问题的简短摘要(适合我的问题更好)将是这样的:

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

Answer 1

我不是 DDD 专家（只浏览了 Eric Evan 书中的 100 页），但我可以告诉您在我们的电子商务目录案例中发生了什么。

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

我们转向了 CQRS 实现，因此我们的很多业务逻辑都是“预先计算的”，因此它位于“合作伙伴上下文”之类的东西中，作为我们从写入模型到读取模型的投影的一部分。我们不专门存储链接，而是标记数据上允许的行为。目录应用程序和搜索应用程序都使用此读取模型及其行为标志来确定要呈现给客户端的状态转换。

有些事情是在请求资源时即时发生的，几乎是在序列化步骤中。我们的目标是尽可能将这些内容转移到预先计算中，但我们无法预先计算（仅因为规模）的是专门基于用户的内容。就像推荐搜索一样，它使用搜索引擎内的BI数据来返回结果。我们可以预先计算每个用户的数量，但目前这个数字对于我们的系统来说太大了。因此，我们发送主应用程序计算的资源（来自主上下文）并将其传递到另一个合作伙伴上下文以进一步完善内容。

另一个用例是某些链接仅呈现给经过身份验证的用户，因此对匿名用户隐藏。我们在主应用程序上下文中执行此操作，但这开始有点障碍，因为它们的存在表明请求背后的用户可以在其他应用程序中执行哪些操作（例如更改密码），而我们的上下文并不是真正的权限用户可以在其他应用程序中执行此操作。最好将资源交给他们的上下文并让他们在我们将其返回给用户之前对其进行处理。我们为此使用的一个简单解决方案是，我们链接到该上下文的根资源并允许它呈现状态转换，而不是深度链接到外部上下文中的函数。这意味着有 2 个请求，但它清理了逻辑的位置/权限。