domain-driven-design – 如何使用Event Sourcing实现复杂表单的命令和事件？

概述我想使用Axon框架实现CQRS和ES 我有一个非常复杂的HTML表单,代表招聘流程有六个步骤. ES将有助于生成所选日期的历史统计数据并跟踪表单中的更改. 管理员总是可以执行多项 *** 作： >指派负责每一步的人 >为每个步骤提供注释 >每一步都接受或拒绝候选人 >打开/关闭短信或电子邮件通知 >分配标签 表单更新(仅限差异)从UI应用程序发送到后端. 假设我只想对服务器端应用程序进行更改,那么问题应 我想使用Axon框架实现CQRS和ES

我有一个非常复杂的HTML表单,代表招聘流程有六个步骤.
ES将有助于生成所选日期的历史统计数据并跟踪表单中的更改.

管理员总是可以执行多项 *** 作：

>指派负责每一步的人
>为每个步骤提供注释
>每一步都接受或拒绝候选人
>打开/关闭短信或电子邮件通知
>分配标签

表单更新(仅限差异)从UI应用程序发送到后端.

假设我只想对服务器端应用程序进行更改,那么问题应该是什么应该是命令以及什么应该是一个事件,我考虑三个选项：

>表单补丁是一个生成表单更新事件的命令

>此解决方案的缺点是每个事件处理程序都需要检查表单中的更改是否引用此处理程序ex.如果发送关于拒绝的电子邮件

>表单补丁是一个命令,它生成几个事件ex：.面试官已分配,通知已关闭,技术面试被拒绝

>此解决方案的缺点是可能会生成某些事件而其他事件不会因为违反约束而被解除：通知已关闭将成功但由于分配未经授权的用户,IntervIEwer Assigned将失败.也许我应该在命令生成之前检查所有约束？

>表单补丁转换为多个命令ex：分配IntervIEwer,关闭通知,每个命令生成事件ex：IntervIEwer Assigned,Notifications off Off

>此解决方案的缺点是某些命令可能会失败ex：分配IntervIEwer可能由于分配未经授权的用户而失败.这将导致状态不一致,因为某些事件将存储在存储库中,有些则不会.也许我应该在命令生成之前检查所有约束？

解决方法 我要提醒您注意的问题是：您是否为您存储的信息创建权限,或者您只是跟踪来自外部世界的信息？

Udi Dahan写了Race Conditions Don’t Exist;提出这个有趣的观点

A microsecond difference in timing shouldn’t make a difference to core business behaviors.

如果您的系统中有未经授权的用户,那么在为特定步骤分配责任之前,对他们授权的业务是否真的至关重要？系统能否真正告诉“故障”是责任分配给错误的用户,而不是用户被错误地授权？

Greg Young谈到了exception reports in warehouse systems,指出在这种情况下模型的责任不是阻止数据更改,而是报告数据更改何时产生不一致的状态.

如果您更新数据,业务成本是多少？

如果消息的语义是已经做出决定,或者现实世界中的某些内容已经改变,那么您的模型不应该试图阻止该信息被记录.

FormUpdated并不是一个特别令人满意的事件,因为你提到的原因;你必须做一些额外的工作,以特定领域的术语来施展它.如果有选择,你宁愿这样做一次.在你进行的过程中,从将域不可知形式转换为域特定形式的事件进行思考是合理的.

httpRequestReceived ->Formsubmitted ->IntervIEwerAssigned

中间表示是短暂的.

总结

以上是内存溢出为你收集整理的domain-driven-design – 如何使用Event Sourcing实现复杂表单的命令和事件？全部内容，希望文章能够帮你解决domain-driven-design – 如何使用Event Sourcing实现复杂表单的命令和事件？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。