Architecture CQRS体系结构优化和变化

命令查询责任分离/事件源架构显然适合我正在启动的一个项目，该项目每年将看到约10亿笔与人民健康保险相关的金融交易。其主要好处是审核历史记录、可扩展性、跨多个团队实施异步兼容UI、将这些事务从read数据库中分离、通过事件队列简化状态向间歇性连接的外地办事处的传输，以及在整个系统生命周期内应对重大业务逻辑变化

然而，在某些领域，CQR/E可能会出现问题，例如，将数字ID分配给100mn用户，用户安全性最终的一致性是不可接受的。系统中还有一些区域本质上是积垢，不能从CQR/ES中获益。最后，我们将在不同的团队和公司中拥有大量的开发人员，最好是在不需要CQR/ES能力的领域。如果某些区域不是事件来源，是否可以采用混合方法？我们可以同步读写端的相关表吗

CQRS体系结构的聚合实体是否简化了快照缓存失效？任何更新可能被缓存的聚合实体的事件都可以被失效者监听，并且给定的聚合实体比关系实体粒度更粗，我们可以区分写入事件。这个问题是否可以解决

我预计每年大约有10亿起事件，需要追踪大约4年的历史。我们可以快照和归档旧事件吗

是否有不同程度的事件来源？例如，一个在线商店系统

AddLineItem

事件可能包括每单位商品的价格，但依赖于读取端在发票上提取并呈现商品名称。另一个在线商店可能会在事件数据中包含该名称。您如何选择活动中包含的内容？在医疗保险中，它可能会限制“假设”分析的运行——如果我们没有包括被保险人的年龄，我们就无法切实模拟需要它的保单

有没有一种有趣的方法来模拟事件？例如，管理员在系统中输入产品价格将在未来某个日期发生变化的信息。我想快照将是一个价格时间表。我们是否可以添加一个过期的ProductPriceChanged事件？在运行“假设”场景时，我们是否可以伪造此类事件？（为了避免版本号和并发检测问题，此类聚合必须很少更改。）

CQRS/ES通常被认为使系统更容易适应未来的业务流程变化。我理解这样一种观点，即用泛在语言列出事件的命令使讨论和重新配置事件变得更容易，而事件源消除了RDBMS模型的一些刚性。但是，事件中的任何更改不会破坏事件的重播吗？随着系统的不断变化，您不会遇到很多版本化的事件吗？例如，在一家在线商店中，通过改变标准来评估客户是否持有金卡？你能把一切都拍下来吗？您将如何公布这些更改的日期？类似地，您是否必须小心依赖项注入，因为注入的依赖项都不会影响业务逻辑，否则会破坏replay

你知道为什么它与.NET世界联系在一起，而在行业的其他领域却不那么受欢迎吗

非常感谢您的阅读

如果某些区域不是事件来源，是否可以采用混合方法

当然

我们可以同步读写端的相关表吗

在很多情况下，这听起来是个坏主意

CQRS体系结构的聚合实体是否简化了快照缓存失效

不多？有一个事件表明记录簿发生了写操作，可用于使缓存失效，这一概念并不是一个特别的CQR概念。这一点也不简单——只是额外的工作在范围之内

我们可以快照和归档旧事件吗

是的，但是。。。从一个长寿命的实体的历史被分解成更短的情节，从一个情节滚动到下一个情节，例如，考虑在财务期结束时翻阅账簿，通常比较容易。然后，您将归档任何生命终结的聚合的历史记录

您如何选择活动中包含的内容

查看此聚合建立/维护/恢复业务不变量所需的状态。其他的都可以洗了。这通常意味着报告（读取模型）是由多个聚合以及可能的文档组装而成的

有没有一种有趣的方法来模拟事件

关于事件的事件是混乱的。关于流程的事件非常棒

我们是否可以添加一个过期的ProductPriceChanged事件

拼写错误--请尝试

PriceChangeScheduled

。注：建模时间很重要；域模型不应该注意到时间的流逝，除非外部世界提到它

但是，事件中的任何更改不会破坏事件的重播吗

没有，但是您需要维护关于事件表示的一些规则，以确保做到这一点。格雷格·杨正在以电子书的形式写作

模式中的quick和dirty--字段是可选的；你可以添加或删除它们，但你永远不会改变它们的含义。消费者为他们想要阅读的任何内容提供默认值，并且“必须忽略”他们不理解的条目

随着系统的不断变化，您不会遇到很多版本化的事件吗？例如，在一家在线商店中，通过改变标准来评估客户是否持有金卡

我不清楚这是哪个问题。