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