命令查询责任分离/事件采购架构非常适合我开始的项目，每年将有大约10亿次与人们健康保险相关的金融交易。主要优势包括审计历史记录，可扩展性，在多个团队中实施异步兼容的UI，从读取数据库中分离这些事务，通过事件队列简化状态到间歇连接的现场办公室的传输，以及应对重要的业务逻辑变化整个系统的生命周期。
然而，在某些方面，CQRS / ES会出现问题，例如为1亿人分配数字ID，以及最终一致性不可接受的用户安全性。该系统的某些区域本质上是CRUD，并且不受益于CQRS / ES。最后，我们将在不同的团队和公司中拥有大量开发人员，并且拥有不需要CQRS / ES能力的领域将是一件好事。是否有可能采用混合方法，其中某些区域不是事件来源？我们可以只在读写端同步相关表吗？
CQRS架构的聚合实体是否简化了快照缓存失效？更新可能被缓存的聚合实体的任何事件都可以由无效者监听，并且给定的聚合实体比关系实体更粗糙，我们可以区分写事件这个问题是否可以解决？
我预计每年会有大约10亿次活动，需要追踪大约4年的历史。我们可以快照和存档旧事件吗？
是否有度的事件来源？例如，一个在线商店系统AddLineItem事件可能包括每单位的订单项价格，但依赖读取方来提取和呈现发票上的产品名称。另一个在线商店可能在事件数据中包含该名称。您如何选择在活动中包含哪些内容？在健康保险方面，它可能会限制“如果＆＃39;可以运行分析 - 如果我们还没有包括被保险人的年龄，我们可以模拟需要它的政策吗？
是否有一种有趣的方式来模拟有关事件的事件？例如，管理员进入系统，产品的价格将在未来的某个日期发生变化。我想快照将是一个价格时间轴。我们可以改为添加一个过时的ProductPriceChanged事件吗？我们可以在跑步时伪造这样的事件吗？如果＆＃39;场景？ （为避免版本号和并发检测问题，必须很少更改此类聚合。）
通常声称CQRS / ES使系统更易于适应未来的业务流程变更。我理解命令列出无处不在的语言中的事件使得讨论和重新配置它们更容易，并且事件源消除了RDBMS模型的一些刚性。但是， 中的任何更改都会导致事件中的重播失败？如果系统可能会发生变化，您最终会遇到许多版本化事件吗？例如，在网上商店通过更改标准来评估客户是否是金卡持有人？你能快照一切吗？您如何约会这些变化？同样，你必须小心依赖注入，没有注入的依赖项会影响业务逻辑，否则你会破坏重放？
知道为什么它与.NET世界有关，而在该行业的其他领域不那么受欢迎？
巨大感谢即使只是阅读。
答案 0 :(得分：6)
是否可以采用混合方法，其中某些区域不是事件源？
当然。
我们可以只在读写端同步相关表吗？
在许多情况下，这听起来不错。
CQRS架构的聚合实体是否简化了快照缓存失效？
不多？记录簿中发生了写入事件的事件的概念，可以用来使缓存无效，这不是一个特别的CQRS想法。它并不简单 - 只是额外的工作在范围内。
我们可以快照和归档旧事件吗？
是的但是......从长期存在的实体被分解为较短的剧集的历史，以及从一集到下一集的状态滚动，通常更容易思考 - 例如，考虑滚动在财政期间结束时的分类账。然后归档任何即将结束的聚合的历史记录。
您如何选择在活动中包含哪些内容？
查看此聚合所需的状态，以建立/维护/恢复业务不变量。其他所有东西都可以洗了。这通常意味着报告（阅读模型）是从多个聚合中汇总的，也可能是文档。
是否有一种有趣的方式来模拟有关事件的事件？
有关事件的事件很乱。关于进程的事件非常棒。
我们可以改为添加一个过时的ProductPriceChanged事件吗？
拼写错误 - 尝试PriceChangeScheduled。注意：建模时间很重要;域名模型不应该注意时间的流逝，除非外界提到它。
但是，如果事件中的任何变化都会破坏事件的重播吗？
不，但是您需要维护有关事件表示的规则，以确保这样做。 Greg Young正在撰写Versioning in an Event Sourced System作为电子书。
快速和脏 - 模式中的字段是可选的;你可以添加或删除它们，但你永远不会改变它们的含义。消费者为他们想要阅读的任何东西提供默认值，并且＆＃34;必须忽略＆＃34;他们不理解的条目。
如果系统可能会发生变化，您最终会遇到许多版本化事件吗？例如，在一家在线商店通过更改标准来评估客户是否是金卡持卡人？
我不清楚这是哪个问题。可能存在多个事件表示（取决于期望的架构以及考虑的默认值），但它仍然只是一个事件。系统做出的决策都是通过事件记录的，因此随着时间的推移版本并没有真正进入它。
同样，您必须小心依赖注入，注入的依赖项都不会影响业务逻辑，否则会中断重播？
业务逻辑都存在于域模型中，域模型位于洋葱的中心;脱离现实世界。因此，您不应该注入任何在现实世界中引入副作用的依赖项。这些通常是异步处理的（我们成功保存了这些事件，因此可以安排副作用）。
知道为什么它与.NET世界有关，而在该行业的其他领域不那么受欢迎？
人。 Udi Dahan和Greg Young都有.NET背景。在PHP中也很受欢迎，因为Mathias Verraes有这样的背景。
您如何建议我坚持非ES聚合实体？
文件商店？ RDBMS？平面文件？多语言持久性很好。
我可能会想念这是如何回答这个问题的 - 如果商业不变量是一个订单行项目，这包括产品名称还是只是价格？
产品ID和数量可能已足够。也许是报价，如果您的业务报价可能与目录中列出的报价不同。
我的意思是，如果聚合的业务逻辑发生变化，但过去的事件仍然需要处理旧的方式。
一个关键的想法是事件的意义不应该改变;他们描述了状态的变化。因此，如果您发现＆＃34;新版本的事件＆＃34;意味着不同的东西，那么你真的有一个新的事件。见杨的书。
汇总业务逻辑 - 决定如何从一个州演变到下一个州;这确实改变了。但它并没有改变给定聚合实际所处的状态。
例如，您可能会发现某些州无法访问。这个业务逻辑 - 聚合不应该写新事件以最终进入该状态。这并不会以任何方式影响当前处于无法访问状态的聚合;他们还在那里，因为历史就是他们的所在。你通过给他们更多的事件将他们从这种状态中移出。