CQRS架构(1)

最新推荐文章于 2024-08-23 15:54:50 发布

2401_84003554

最新推荐文章于 2024-08-23 15:54:50 发布

阅读量330

点赞数 5

文章标签： java 面试学习

本文链接：https://blog.csdn.net/2401_84003554/article/details/138946175

版权

总结：心得体会

既然选择这个行业，选择了做一个程序员，也就明白只有不断学习，积累实战经验才有资格往上走，拿高薪，为自己，为父母，为以后的家能有一定的经济保障。

学习时间都是自己挤出来的，短时间或许很难看到效果，一旦坚持下来了，必然会有所改变。不如好好想想自己为什么想进入这个行业，给自己内心一个答案。

面试大厂，最重要的就是夯实的基础，不然面试官随便一问你就凉了；其次会问一些技术原理，还会看你对知识掌握的广度，最重要的还是你的思路，这是面试官比较看重的。

最后，上面这些大厂面试真题都是非常好的学习资料，通过这些面试真题能够看看自己对技术知识掌握的大概情况，从而能够给自己定一个学习方向。包括上面分享到的学习指南，你都可以从学习指南里理顺学习路线，避免低效学习。

大厂Java架构核心笔记（适合中高级程序员阅读）：

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

删除记录

最简单情况下，我们的交互都是关于存储和检索这些记录。随着我们的需求变得越来越复杂，可能希望

以与记录存储不同的方式查看信息，也许将多个记录折叠成一个记录，或者通过组合不同位置的信息来形成虚拟记录
更新方面，我们可能会发现验证规则，这些规则仅允许存储某些数据组合，甚至可能推断出与我们提供的数据不同的数据

发生这种情况时，我们开始看到信息的多种表示形式。当用户与信息交互时，他们使用该信息的各种表示形式，每个表示形式都是不同的表示形式。

开发人员通常会构建自己的概念模型，以用来操纵模型的核心元素。如果使用域模型，则通常是域的概念表示。通常，还应使持久性存储尽可能接近概念模型。表示形式的多层结构可能会变得非常复杂，但是当人们这样做时，他们仍然将其解析为单个概念表示，该概念表示充当所有演示之间的概念整合点。

CQRS引入的更改是将概念模型拆分为单独的模型以进行更新和显示，按照CommandQuerySeparation的词汇分别称为Command和Query。这样做的理由是，对于许多问题，尤其是在更复杂的领域中，使用相同的命令和查询概念模型会导致更复杂的模型，但效果却不佳。

通过单独的模型，我们最通常地表示不同的对象模型，它们可能在不同的逻辑过程中运行，也许在单独的硬件上。

一个网络示例将使用户看到使用查询模型呈现的网页。如果他们发起更改，则将更改路由到单独的命令模型进行处理，结果更改将传达给查询模型以呈现更新的状态。这里有很大的变化空间。内存中模型可以共享同一数据库，在这种情况下，数据库充当两个模型之间的通信。但是，他们也可以使用单独的数据库，从而有效地将查询方的数据库转换为实时ReportingDatabase。在这种情况下，两个模型或其数据库之间需要某种通信机制。这两个模型可能不是单独的对象模型，可能是相同的对象在其命令端和查询端具有不同的接口，就像关系数据库中的视图一样。

但通常当我听说CQRS时，它们显然是分开的模型。 CQRS自然适合其他一些建筑模式。当我们远离通过CRUD与之交互的单个表示形式时，我们可以轻松地转到基于任务的UI。
CQRS非常适合基于事件的编程模型。常见的是，CQRS系统被拆分为与事件协作进行通信的单独服务。这使这些服务可以轻松利用事件源。具有单独的模型会引发有关如何保持这些模型一致的难度，这会增加使用最终一致性的可能性。对于许多域，更新时需要很多逻辑，因此使用EagerReadDerivation简化查询侧模型可能很有意义。如果写入模型为所有更新生成事件，则可以将读取模型构造为EventPosters，使它们成为MemoryImages，从而避免大量数据库交互。
CQRS适用于复杂领域，该领域也可以从领域驱动设计中受益。何时使用它与任何模式一样，CQRS在某些地方有用，但在其他地方则没有用。许多系统确实适合CRUD思维模型，因此应采用这种风格。对于所有相关人员来说，CQRS是一次重大的思想飞跃，因此，除非收益值得实现，否则不应解决。尽管我成功地使用了CQRS，但到目前为止，我遇到的大多数情况都不是很好，因为CQRS被视为使软件系统陷入严重困境的重要力量。特别是，CQRS仅应在系统的特定部分使用。