异步SAGA模式中的验证-CQRS和DDD

Question

null

我们尝试了几件事：

>

发出命令：

• 激发命令请求邀请确认
• 同步处理此命令，如果命令无效或引发invitationconfirmationrequested事件，则返回错误。

null

缺点：-据我所知，应该用佐贺来编排流程。这里我们介绍“验证”的概念。我不确定这是不是推荐的方法。

验证是一个非常常见的概念。在分布式完全异步系统中如何处理它？

Answer 1

本系统设计的要点是：“谁是这个API的客户端？”。

• 如果此客户端是内部服务或应用程序，这是一回事（如分布式应用程序、微服务等）。
• 如果API由第三方客户端使用，则是另一回事。

简短回答

如果你在周围搜索，你会看到很多关于错误和验证的讨论，所以下面是我对此的看法。

因为我们要分离我们系统的其他部分，所以分离我们所拥有的错误类型似乎是很自然的。你可以查看这篇关于那个主题的论文。

让我们定义一些错误类型。

null

null

• 验证具有指定ID的邀请是否存在
• 验证邀请尚未过期
• 验证邀请是否尚未处理（接受、拒绝等）

如何处理这将取决于我们如何分离应用程序中的责任。让我们使用DesignByContract原则，定义每一层（域、应用程序等）对其他层的期望。

让我们定义一个规则，不应创建和调度包含invitationid的命令，该命令与现有的invitationid不对应。

在使用API的情况下，接受请求的RouteHandler（应用程序控制器等）必须：

• 亲自执行此验证
• 委托他人进行验证

让我们进一步定义这是applicationlayer的一部分（或者模块、组件等，不管它是如何调用的，所以我将使用Layer)，并使其成为applicationerror。从这里我们可以用许多不同的方法来做。

从现在开始，我们系统中的其他人应该考虑在ConfironminVitationCommand中使用指定的ID的邀请是存在的。如果没有，则将其视为系统中的故障，并应由开发人员和/或管理员进行检查。应该有一个手动方式（一个管理后端）来取消这些无效的命令，所以在开发系统时必须考虑到这一点，不像系统中的故障一样处理。

另外两个验证是域的一部分。

假设你有一个

null

null

>

confirminvitationCommand启动invitationconfirmationsaga

invitationconfirmationsaga将requestconfirmationvitation消息发送到invition

后来呢：

如果邀请未过期，则接受邀请，并将invitationaccepted消息发送到invitationconfirmationsaga

然后：

• invitationconfirmationsaga将接收这些消息并相应地引发事件。