CQRS、事件来源和缩放
很明显，基于这些模式的系统是易于扩展的。但我想问你，具体怎么做？关于可伸缩性，我没有什么问题：
- 如何缩放聚合体？如果我将创建
聚合的多个实例，如何同步它们？如果其中一个实例处理命令并创建事件，则该事件应传播到该agregate的每个实例？ - 不应该有一些业务逻辑来表示要请求的agregate的哪个实例吗？因此，如果我发出多个命令，这些命令适用于
聚合一个ORDERS并适用于一个特定的订单，那么将其交付给同一个实例是有意义的。还是？
共有1个答案
如何缩放骨料？
>
仔细选择聚合，确保命令在许多聚合之间合理地分布。您不希望拥有可能从并发用户接收大量命令的聚合。
序列化发送到聚合实例的命令。这可以通过聚合存储库和命令总线/队列来完成。但对我来说，最简单的方法是使用聚合版本控制进行乐观锁定，正如Michiel Rook在这篇文章中所描述的那样
这种方法是可伸缩的，允许您进行无服务器操作--每个命令调用一个lambda调用，其间没有共享状态。当聚合具有太多事件时，这些罕见的情况可以通过快照来解决。
-
我想创建一个CQRS和事件源架构，非常便宜，非常灵活，非常简单。 我想确保事件永远不会失败，至少到达发布者/事件存储，永远，因为这是业务所在。 天蓝 有了azure，我似乎不知道该用什么。 Azure服务总线 蔚蓝函数 Azure webjob（我想这可以用Azure函数代替） ？？（还有什么我忘了或者不知道的？） null 你的经验说明了什么？ 其他替代方案呢？（例如:)？
-
当我在读一些CQRS的资料时，有一个反复出现的问题我没有理解。例如，假设一个客户端发出一个命令。该命令由域集成，因此它可以刷新其域模型(DM)。另一方面，命令保存在事件存储中。这是最常见的情况。 1） 当我们说DM被刷新时，我假设数据被保存在底层数据库中（如果有的话）。我说得对吗？否则，我们将处理内存瞬态模型，我想这不是一件好事吗？（在客户端请求之外，状态不应该保留在服务器端的内存中）。 2）如果
-
我开始阅读与CQRS相结合的事件源模式。据我所知，CQRS模式是一种将写操作和读操作分开的模式。事件源是一种模式，系统中的一切都由触发事件的命令启动。事件源模式需要一个事件总线。有几件事我没弄明白。 事件存储区包含发生在某个实体上的所有事件。如果我想查询这个实体的当前状态，我需要查询发生在这个实体上的所有事件，并重新创建它的当前状态。 所有事件历史记录都在事件存储区中。 为什么我不能有一个负责将每
-
我在CQRS/ES设计中有一个计时案例。为了便于讨论，让我们以Microsoft关于这个主题的示例会议管理为基础(https://msdn.microsoft.com/en-us/library/jj554200.aspx)。 假设在第1分钟创建会议（最大座位数为20）。 在第4分钟，事件到达order mgmt上下文，因此创建了一个座位可用性。 在第7分钟，用户下了一个订单（通过订单管理），购买
-
事件源和CQRS很棒，因为它让rids开发人员被一个预先建模的数据库所困，除非有一个大的数据迁移项目，否则开发人员必须在应用程序的生命周期内使用该数据库。CQRS和ES还有其他好处，比如扩展eventstore、审计日志等，这些都已经遍布互联网。 但是缺点是什么呢？ null
-
我有一个在AWS Lambda上运行的基于微服务的应用程序。其中两个微服务，最关键的，使用事件源/cqrs。 背景：（这也是我整理思想的地方） 我正在使用这个库并将事件存储在DynamoDB中，并将预测存储在AWS S3中。 写入部分的工作方式很有魅力：每个命令调用都从DynamoDB加载聚合的当前状态（通过处理程序运行事件和/或加载缓存的聚合），它根据一些业务逻辑决定接受或拒绝命令，然后使用键条