本文主要是介绍Lagom零时：CQRS概念，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
CQRS代表Command Query Responsibility Segregation。
个人用于与数据系统交互的方法是将其视为CRUD数据存储。通过这个，我的意思是我们有一些记录结构的心理模型。我们考虑在完成后生成新记录，扫描记录，更新现有记录和删除记录。在最简单的情况下，我们的交互都是关于存储和检索这些记录。
如果不考虑用户界面，您无法真正享受CQRS的优势。创建它可以明确地捕获用户目的，同时考虑到客户端验证和命令结构也可以稍微平衡。
传统方法
当这种情况发生时，我们开始可视化多种知识表示。移动数据后，您可以使用此信息的各种显示，所有这些都可能是完全不同的表示。开发人员通常构建自己的抽象模型，用于控制模型的核心组件。如果您使用域模型，那么这通常可以是域的复杂说明。您通常还会在抽象模型的点上创建持久存储。
CRUD方法的问题
多层表示的这种结构将变得相当复杂，然而，人们可以做的仍然是将其解析为一个概念表示，其充当所有显示之间的概念集成点。
随着我们的需求变得更加先进，我们倾向于逐步摆脱这种模式。我们倾向于以与记录方式完全不同的方式查看知识，可能将多个记录合并为一个或通过组合信息形成虚拟记录。在更新中，我们倾向于注意到验证规则，这些规则能够保持知识的组合，甚至可以推断出要保留的知识，这与我们提供的完全不同。
CQRS方法
通过分离模型，我们通常意味着完全不同的对象模型，最有可能在几个逻辑进程中运行，也可能在不同的硬件上运行。在线示例将是查看用户查看使用查询模型执行的互联网页面。如果它们启动更改，则将修改路由到单独的命令模型以进行处理，并将得到的更改传递给查询模型以呈现更新的状态。
CQRS的好处
- CQRS允许您将负载与读取和写入分开，允许您独立地扩展每个。如果您的应用程序在读取和写入之间看到增益不平等，这通常非常方便。即使没有这个，你也会对双方采用完全不同的改进方法。
- 在不匹配的域上使用CQRS，会增加复杂性，从而降低生产力并增加风险。
CQRS中的写入侧与读取侧
这种模式的好处是写入和读取方面之间的关注点分离。然后，实体可以专注于更新命令，并且可以针对各种查询和报告作业优化读取侧。尝试封装读取和写入操作的单个概念模型可能不会很好。
重要的是要意识到写入侧与读取侧具有完全不同的需求，并且将这些关注分开使得可以独立地为写入和读取侧提供最佳体验。
这种分离对于可伸缩性也很有用，因为读取端可以独立于写入端扩展到许多节点，并且通常在读取端需要大量可伸缩性。
分离读取侧的结果是它最终是一致的，即可能需要几秒钟才能在读取侧看到写入侧的更新。
谨慎使用CQRS
不是银弹，每个案例都不适合这种CQRS方法。
许多系统都适合CRUD心理模型，它们应该从这种风格中消失。CQRS可能是所有相关人员的一次重要的精神飞跃，因此除非利润绝对值得跳跃，否则不应该加以解决。CQRS应该仅用于系统的特定部分而不是整个系统。
Lagom是一个基于Akka和Play框架构建的开源微服务框架。Lagom Persistence利用Event Sourcing和CQRS来帮助实现解耦架构。
您可以在以下博客中找到Lagom如何处理事件采购和CQRS的真实示例：
这篇关于Lagom零时：CQRS概念的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
