这篇文章主要讲解了“3种CQRS架构模式介绍”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“3种CQRS架构模式介绍”吧！
CQRS 建议将应用程序层分为两个方面，即命令端（Command）和查询端（Query）。
查询端负责优化读取数据。从持久化获取数据，然后将它们映射到展现层表单，这些表单通常被标识为数据传输对象（DTO）。
命令端关注优化写入数据。命令执行各种用例，修改实体状态并将其持久化。
通过分离读写操作，我们提高了性能，并在系统中支持关注点分离原则。
本文介绍 3 种主要的 CQRS 架构实现。
单一数据库CQRS 模式没有正式名称，Mattew Renze 在他的课程Clean Architecture 中将其命名为单一数据库 CQRS，我也选择这个命名。
顾名思义，双方都在和一个数据库对话。Command 在域中执行用例，从而修改实体的状态，然后通过 ORM 如 Entity Framework Core 或 Hibernate 将实体保存到数据库中。
Query 直接通过数据访问层执行，数据访问层要么是使用各种 ORM，要么通过存储过程。
在“双数据库”方式中，我们需要两个数据库，一个用于写操作，一个用于读操作。命令端使用针对写操作优化的数据库。查询端使用针对读取操作优化的数据库。
命令每改变一个状态，修改后的数据就必须从写数据库推送到读数据库中，或者作为一个跨两个数据库的分布式事务，或者使用最终一致性模型。
这种架构给软件的查询端带来了数量级的性能提升，这是有利的，因为一般系统在读数据上花费的时间一般比写数据要更多。
最后一种是最复杂的 CQRS 架构。与前面两种方式相比，事件源存储数据的思路完全不同。
在事件源方法中，我们并不只存储实体的当前状态，而且将实体发生的每一个状态作为快照来存储。实体并不是以标准化数据的形式保存，而是通过事件的时间戳来保存它们的变更。
事件源带有以下好处：
事件存储包括完整的审计跟踪，可以在需要严格监管的场景中派上用场。
可以在任何时间点重建任何实体的任何状态，这对于调试非常有用。
可以重放事件，查看系统中任何时候到底发生了什么。这个功能对于压力测试和 bug 修复非常有用。
可以轻松地重建生产数据库。
有多个为读优化的数据存储。
但在另一方面，这种方式实现很复杂，如果你不能从其中受益，那么用这个模式可能适得其反。
感谢各位的阅读，以上就是“3种CQRS架构模式介绍”的内容了，经过本文的学习后，相信大家对3种CQRS架构模式介绍这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
