Architecture 意图命令事件

我正在创建一个web CRUD应用程序，该应用程序在处理内部逻辑后，将向其他系统发布事件以更新其数据

我正处于实现CQR的第一步，我必须以一种只有一个“保存”按钮的形式为用户的所有可能意图创建特定命令，这听起来很奇怪。这意味着需要大量的命令（针对每个属性或价值对象）来捕获一个意图在我的需求中不需要，但在即将订阅它的项目中需要。我是一个只做有界上下文所需的事情的粉丝

另一件需要考虑的事情是： 我必须使用会话来比较数据是否已更改。保存数据后伪造数据将隐藏在UI中显示错误数据的并发情况

---

编辑：我刚找到Greg Young建议的地方，有些屏幕只是粗糙的，将更新作为默认行为没有什么不好的。

为什么要使用CQR？它并不适用于所有情况

---

具体来说，如果您使用的是CRUD，那么可能根本没有理由尝试CQR。它就是不合身。当用户的意图在UI端被明确捕获并以有意义的命令传递给服务器时（这不是FieldNameUpdated，而是CustomerRelocatedToNewAddress或CustomerAddressCorrected），CQRS从设计中受益匪浅。这需要在设计中使用领域驱动的设计方法。）

我就是这样做的。我的CRUD项目是一个内部“配置工具”，用于在高流量网站中显示正确的数据，因此我需要发布事件。我的完美解决方案是只使用DDD实现这个项目，不使用CQR，并为我范围内的每个真实意图发布一个事件。该网站应使用CQR实现，因为它将拥有数千名用户。我不明白为什么我需要创建这么多命令，而我的需求只是说‘创建一个带有保存按钮的表单’。如果CQRS的唯一原因是可伸缩性，那么您可以尝试更简单的方法。例如：使用某种内存缓存来减少网站上的负载（或者以一种不强调数据库的方式发布web视图-例如：CDN上的JSON），或者只是调整默认服务器缓存。当项目需要处理以下几个方面时，CQR通常会出现：处理复杂的业务场景、规模、具有丰富的BI功能、适应快速变化的需求。场景很复杂，系统已经使用memcache运行。我们可以从CQRS实践中获得很多好处，毫无疑问，这个决定将用CQRS重建网站。疑问主要是指那些网站上的小项目，以及他们应该发送大命令还是小命令（事件也是如此）。所有这些想法都来自于一位具有强大DDD背景、有限上下文和成功交付的开发人员。现在我必须对所有意图进行编码并处理会话，以保持数据的版本。（顺便说一句，我喜欢看你的博客）谢谢你花时间澄清这个问题！事实上，看起来单个命令可能更好（在这种情况下，选择更简单）。至少，由于项目很小，如果您遇到细化域的需要，用更细粒度的实体替换UpdateCommand将不是一个大问题。