我正在实现一个基于 CQRS/ES 的系统，该系统带有一个 Web 应用程序使用的 RESTful 接口。
当执行某些操作时，例如创建新配置文件 我需要能够检查某些条件，例如配置文件 ID 的唯一性，或者该人有权在组下创建资源。这意味着我有两个选择：
上下文：POST/profiles { "email": "unique@example.com" }
通过我的 REST API 从我的服务返回 202，并带有新资源的位置，我的客户可以在其中轮询它。但是，在这种情况下，我该如何处理错误，因为实际上视图将不存在或永远存在。
在初始请求上创建一个 saga，然后分派事件。一旦我的服务创建视图或发现错误，结果就会写入 saga。当 saga 完成后，将结果返回给用户。
从这两个选项中，第二个选项对我来说似乎更合理，如果不是更复杂的话。这是在 CQRS/ES 事件源后端构建 RESTful 请求/响应模型的可行选项吗？
【问题讨论】：
标签： cqrs event-sourcing saga
是的，第二种解决方案似乎更适合业务。
根据我从您的案例中了解到的情况，从DDD 的角度来看，创建用户配置文件是一个业务流程，包含多个步骤（验证配置文件的唯一性、创建配置文件并从重复的个人资料情况）。这个过程就像一个实体，它开始、运行并以结果（成功或错误）结束。作为一个实体，它有一个 ID，它可以被视为一个 REST 资源。 Saga 将负责执行它。
因此，为了响应客户端的请求，您发送进程资源的 URI，客户端可以在其中轮询状态。如果出现错误，它会读取错误消息。如果成功，它会获取其配置文件的 URI。
如果用例更简单，如果命令可以同步执行并且客户端立即获得最终结果（错误或成功），则仍然可以使用第一种解决方案。
【讨论】：
从我的 REST API 返回 202，从我的服务返回新资源的位置，我的客户可以在该位置轮询它。但是，在这种情况下，我该如何处理错误，因为实际上视图将不存在或永远存在。
这里通常的回答是，作为202 Accepted 响应的一部分，您包含监控信息
与此响应一起发送的表示应该描述请求的当前状态，并指向（或嵌入）一个状态监视器，该监视器可以为用户提供对何时完成请求的估计。
换句话说，当接受的请求最终运行时，该资源的链接将发生变化。
因此，在描述协议时，除了您创建的资源之外，您还需要记录延迟工作时使用的表示，以及监视器使用的表示。
saga 完成后将结果返回给用户。
根据工作，这可能是矫枉过正。
也就是说，您在这里提出了两个不同的问题；其中之一是应该同步处理请求（在工作完成之前不响应）还是异步处理（立即返回，但为客户端提供监控进度的方法）。
另一个问题是从业务层看工作如何。如果您需要多个事务来进行更改，并且您可能需要在流程的某些变体中“恢复”以前提交的事务，那么 saga（或 process manager）是有意义的。
Set Validation - 强制执行像“唯一性”这样的不变量的广义术语 - 很尴尬。确保您学习，并确保您和企业了解失败的影响。
【讨论】：