具有单数据库读/写事件源的CQRS模式
现在，每当在我的数据库中的表上发生插入/更新/删除时，我需要向其他系统发送消息，这些系统需要了解我的系统中的更改，因为我的数据库是主数据，所以这里发生的任何更改都需要投射到下游系统，以便它们获得最新的数据并在其系统中维护这些数据。为此，我可以使用MQ或Kafka，所以每当有变化时，我可以生成关键消息并将其放入MQ或使用Kafka进行消息传递。
到目前为止，我还没有像我想的那样使用事件源，因为我没有多个数据库进行读/写，所以我可能不需要事件源，如果我们有一个数据库，我们不需要事件源，我的假设是正确的吗？或者事件源可以在使用MQ或Kafka中发挥任何作用，我的意思是，如果我使用事件源模式，我可以先在主数据库中保存数据，然后使用事件源模式将更改写入MQ，或者使用Kafka写入消息，我在这里不知道如果我们可以对MQ或Kafka使用事件源模式。
我是否需要事件源写消息到MQ或使用Kafka？或者在我的情况下根本不需要，因为我只有一个数据库，我不需要知道发生在记录系统上的一系列更新，我所关心的是主数据库中记录的最终状态，然后使用MQ或Kafka将更改发送到下游系统，那里有CRUD操作，这样它们就会有最新的更改。
共有1个答案
我的假设是正确的，如果我们有一个单一的数据库，我们不需要事件来源？
不，那个假设是错误的。
在CQRS“传统”中，事件源指的是在持久的数据结构中维护信息；当新的信息到达时，我们将这些信息附加到我们已经知道的信息上。换句话说，它描述了我们用来记忆信息的模式。参见Fowler2005。
完全合理的做法是“原地”修改您的模型，然后发布一条消息，宣布事情已经发生了变化。
当我只有一个数据库并且不关心记录的一系列更改而只关心数据的最终状态时，为什么需要事件源，
你没有。
-
我有一个在AWS Lambda上运行的基于微服务的应用程序。其中两个微服务，最关键的，使用事件源/cqrs。 背景：（这也是我整理思想的地方） 我正在使用这个库并将事件存储在DynamoDB中，并将预测存储在AWS S3中。 写入部分的工作方式很有魅力：每个命令调用都从DynamoDB加载聚合的当前状态（通过处理程序运行事件和/或加载缓存的聚合），它根据一些业务逻辑决定接受或拒绝命令，然后使用键条
-
我在CQRS/ES设计中有一个计时案例。为了便于讨论，让我们以Microsoft关于这个主题的示例会议管理为基础(https://msdn.microsoft.com/en-us/library/jj554200.aspx)。 假设在第1分钟创建会议（最大座位数为20）。 在第4分钟，事件到达order mgmt上下文，因此创建了一个座位可用性。 在第7分钟，用户下了一个订单（通过订单管理），购买
-
很明显，基于这些模式的系统是易于扩展的。但我想问你，具体怎么做？关于可伸缩性，我没有什么问题： 如何缩放聚合体？如果我将创建
-
我想创建一个CQRS和事件源架构，非常便宜，非常灵活，非常简单。 我想确保事件永远不会失败，至少到达发布者/事件存储，永远，因为这是业务所在。 天蓝 有了azure，我似乎不知道该用什么。 Azure服务总线 蔚蓝函数 Azure webjob（我想这可以用Azure函数代替） ？？（还有什么我忘了或者不知道的？） null 你的经验说明了什么？ 其他替代方案呢？（例如:)？
-
首先，我将用现实生活中的例子来解释我的问题。假设我们是一家公司，我们销售不同的运输工具，例如汽车、公共汽车、卡车、火车、飞机等。假设我们有大约10,000,000种不同的产品，每天都有变化。 对于每个项目，我们都有一个唯一的名称（例如，汽车奥迪A8 X或飞机波音747-200by)，其中X和Y是唯一的值。不用担心命名，因为它工作很好。 对于每一项，我们也有一些特殊的数据。数据取决于类型，例如汽车：
-
我们需要重写具有复杂业务逻辑的旧遗留应用程序。我们考虑使用cqrs和事件源。但是不清楚如何从旧数据库迁移数据。可能我们只需要将其迁移到读取数据库，因为我们不能复制所有事件来填充事件存储。但是我们至少需要在事件存储中为每个聚合创建一些初始记录，例如？或者我们需要编写一个脚本，并使用所有命令一个接一个地重新创建聚合，就像我们通常使用事件源一样？