当前位置: 首页 > 知识库问答 >
问题:

使用事件源和CQRS的缺点是什么?

宰父远
2023-03-14

事件源和CQRS很棒,因为它让rids开发人员被一个预先建模的数据库所困,除非有一个大的数据迁移项目,否则开发人员必须在应用程序的生命周期内使用该数据库。CQRS和ES还有其他好处,比如扩展eventstore、审计日志等,这些都已经遍布互联网。

但是缺点是什么呢?

    null

共有1个答案

糜正业
2023-03-14

以下是我对此的看法。

>

  • CQRS+ES通过具有丰富的领域对象、简单的数据html" target="_blank">模型、历史跟踪、对并发问题的更多可见性、可伸缩性等,可以使复杂软件系统中的事情变得简单得多。它确实需要以不同的方式思考系统,因此很难找到合格的开发人员。但是CQRS使得在开发人员之间分离职责变得更加简单。例如,初级开发人员可以纯粹地与读取端一起工作,而不必接触业务逻辑。

    数据副本肯定需要更多的磁盘空间。但如今存储相对便宜。它可能需要It支持团队进行更多的备份,并计划如何在出现问题的情况下恢复系统。然而,如今的服务器虚拟化使其成为一个更精简的工作流程。此外,在没有单片数据库的情况下,在系统中创建冗余要容易得多。

    如果为事件存储选择了正确的数据库,可以以JSON或XML等序列化格式查询事件。这应该只是为了分析的目的。除了聚合根id和事件类型之外,系统内的任何内容都不应该查询事件存储。该数据将被索引并存在于序列化事件之外。

  •  类似资料:
    • 我开始阅读与CQRS相结合的事件源模式。据我所知,CQRS模式是一种将写操作和读操作分开的模式。事件源是一种模式,系统中的一切都由触发事件的命令启动。事件源模式需要一个事件总线。有几件事我没弄明白。 事件存储区包含发生在某个实体上的所有事件。如果我想查询这个实体的当前状态,我需要查询发生在这个实体上的所有事件,并重新创建它的当前状态。 所有事件历史记录都在事件存储区中。 为什么我不能有一个负责将每

    • 很明显,基于这些模式的系统是易于扩展的。但我想问你,具体怎么做?关于可伸缩性,我没有什么问题: 如何缩放聚合体?如果我将创建

    • 我想创建一个CQRS和事件源架构,非常便宜,非常灵活,非常简单。 我想确保事件永远不会失败,至少到达发布者/事件存储,永远,因为这是业务所在。 天蓝 有了azure,我似乎不知道该用什么。 Azure服务总线 蔚蓝函数 Azure webjob(我想这可以用Azure函数代替) ??(还有什么我忘了或者不知道的?) null 你的经验说明了什么? 其他替代方案呢?(例如:)?

    • 当我在读一些CQRS的资料时,有一个反复出现的问题我没有理解。例如,假设一个客户端发出一个命令。该命令由域集成,因此它可以刷新其域模型(DM)。另一方面,命令保存在事件存储中。这是最常见的情况。 1) 当我们说DM被刷新时,我假设数据被保存在底层数据库中(如果有的话)。我说得对吗?否则,我们将处理内存瞬态模型,我想这不是一件好事吗?(在客户端请求之外,状态不应该保留在服务器端的内存中)。 2)如果

    • 我在CQRS/ES设计中有一个计时案例。为了便于讨论,让我们以Microsoft关于这个主题的示例会议管理为基础(https://msdn.microsoft.com/en-us/library/jj554200.aspx)。 假设在第1分钟创建会议(最大座位数为20)。 在第4分钟,事件到达order mgmt上下文,因此创建了一个座位可用性。 在第7分钟,用户下了一个订单(通过订单管理),购买

    • 问题内容: 我正在寻找提高某些SQL性能的方法,当前CTE正在脚本中多次使用和引用。我会使用表变量来获得改进吗?(因为代码在函数内,所以不能使用临时表)。 问题答案: 您实际上必须进行性能测试-没有“是/否”答案。根据安迪·利文(Andy Living)上面链接到的文章,CTE只是查询或子查询的简写。 如果您在同一函数中两次或多次调用它,则填充表变量然后加入该表变量或从中选择表变量可能会获得更好的