cqrs - CQRS/ES 系统中的 POST/PUT 响应 REST

Question

我正在实现一个基于 CQRS/ES 的系统，该系统具有由 Web 应用程序使用的 RESTful 接口(interface)。

执行某些操作时，例如创建新的配置文件我需要能够检查某些条件，例如配置文件 ID 的唯一性，或者该人有权在组下创建资源。这意味着我有几个选择:

上下文:POST/profiles { "email": "<a href="https://stackoverflow.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="2c5942455d59496c49544d415c4049024f4341" rel="noreferrer noopener nofollow">[email protected]</a>" }

1. 从我的 REST API 返回 202从我的服务中获取新资源的位置，我的客户可以在其中轮询它。然而，在这种情况下，我如何处理错误，因为实际上 View 将不存在或永远不存在。

2. 根据初始请求创建传奇，然后分派(dispatch)事件。一旦我的服务创建 View 或发现错误，结果就会写入传奇。当 saga 完成后，将结果返回给用户。

从这两个选项来看，第二个对我来说似乎更合理，甚至更复杂。这是在 CQRS/ES 事件溯源后端上构建 RESTful 请求/响应模型的可行选项吗？

Answer 1

是的，第二种解决方案似乎更适合业务。

据我从您的案例中了解到，来自DDD从观点来看，创建用户配置文件是一个业务流程，具有多个步骤(验证配置文件的唯一性、创建配置文件以及从重复的配置文件情况中恢复)。这个过程就像一个实体，它开始、运行并以结果(成功或错误)结束。作为一个实体，它有一个 ID，并且可以被视为 REST 资源。一个Saga将负责执行它。

因此，为了响应客户端的请求，您发送进程资源的 URI，客户端可以在其中轮询状态。如果出现错误，它会读取错误消息。如果成功，它将获取其配置文件的 URI。

如果用例更简单，如果命令可以同步执行并且客户端获得最终结果(错误或成功)作为立即响应，则仍然可以使用第一个解决方案。