我不是事件采购的忠实拥护者，但是对于我目前的任务来说，它是最合适的选择。但是，我仍在努力定义命令和事件。大多数业务应用程序都具有许多源自某些UI形式的简单属性更改。如果表单具有50个不同的属性，那么创建50个不同的命令导致50个不同的命令处理程序和50个不同的事件对我来说是没有意义的。令人惊讶的是，我在网上找不到有关此问题的任何信息。所有示例都只是更新ONE属性，而实际情况并非如此。搜索中出现的最接近的问题是将数据从CRUD系统导入事件源系统的问题。
那么，为什么不创建仅具有一个成员，字符串和对象的Dictionary的简单的PropertiesChanged命令，处理程序和事件，其中Key是已更改的属性，而值是新值？这将使事情变得非常容易，只需一个命令/处理程序/事件，并且当聚合具有新属性时，无需更改代码。
应用和重播仍然有效，我仍然有一个历史记录，每个命令的确切变化。
那么为什么不将其作为默认方法呢？
答案 0 :(得分：1)
那么为什么不将其作为默认方法呢？
部分原因肯定是历史悠久的-首先尝试进行事件源搜索的社区已被domain modeling收购，尤其是domain driven design，task based user interfaces。
从这个角度来看，将您的数据像anemic property bag一样用域不可知的补丁文档进行更新是错误的方向。
尤其是域驱动的设计通常会应用于企业核心业务中的问题-公司希望通过定制调整工具而获得竞争优势的地方。
采用另一种方式：如果PropertyChanged事件流足以满足业务需求，则事件源可能是解决方案的错误方法。
答案 1 :(得分：0)
如果您询问您的领域专家业务流程中发生了什么-很有可能他会将所有内容都描述为财产的变更。他会告诉您“订单已付款”，而不是“属性Order.paid设置为true”。
以同样的方式，您的系统的一部分也会对相关事件做出反应-装运子系统会对ORDER_PAID事件感兴趣。您可以让它侦听所有PROPERTY_CHANGED事件，并且仅对Order.paid从false设置为true时的事件做出反应，但这至少会产生处理开销。
所以我想说，当您将业务事件简化为财产变更时，您将丢失宝贵的信息。
当然，相反的极端情况是为每个可能的属性进行单独的事件-这也不是一件好事。