Questions tagged «event-sourcing»

虽然我已经遇到卡夫卡之前，我刚刚意识到卡夫卡也许可以作为（基础）一CQRS，eventstore。 Kafka支持的主要观点之一： 事件捕获/存储，当然都是HA。 Pub / sub架构 重播事件日志的能力，使新订户可以在事件发生后向系统注册。 诚然，我不是100％精通CQRS /事件源，但是这似乎与事件存储区应该的非常接近。有趣的是：关于Kafka用作事件存储，我实在找不到太多，所以也许我错过了一些东西。 那么，卡夫卡缺少什么东西可以使其成为一个好的活动库？能行吗？用它生产吗？对洞察力，链接等感兴趣 基本上，系统状态是根据系统曾经收到的事务/事件保存的，而不仅仅是保存系统的当前状态/快照（通常这样做）。（将其视为会计中的总帐：最终所有事务都加到最终状态）。这允许进行各种有趣的事情，但请仔细阅读提供的链接。

219 cqrs  event-sourcing  apache-kafka  dddd 

如果我使用的是RDBMS（例如SQL Server）来存储事件源数据，那么架构会是什么样？ 我已经看到一些抽象意义上的变体，但是没有具体的意义。 例如，假设某人拥有一个“产品”实体，那么对该产品的更改可以采用以下形式：价格，成本和说明。我对是否愿意感到困惑： 有一个“ ProductEvent”表，其中包含产品的所有字段，每个更改都意味着该表中有一条新记录，并在适当时加上“谁，什么，什么地方，为什么，何时和如何”（WWWWWH）。更改成本，价格或说明时，会添加一个全新的行来表示产品。 将产品成本，价格和说明存储在具有外键关系的连接到产品表的单独表中。更改这些属性后，请根据需要使用WWWWWH写入新行。 将WWWWWH以及代表事件的序列化对象存储在“ ProductEvent”表中，这意味着必须在应用程序代码中加载，反序列化和重播事件本身，以便为给定产品重新构建应用程序状态。 我特别担心上面的选项2。更极端的是，产品表几乎是每个属性一个表，要加载给定产品的应用程序状态将需要从每个产品事件表中加载该产品的所有事件。这种桌子爆炸对我来说是不对的。 我确定“取决于”，虽然没有一个“正确答案”，但我试图让人们了解什么是可以接受的，什么是完全不可接受的。我也知道NoSQL可以在这里提供帮助，因为事件可以针对聚合根存储，这意味着仅向数据库发出单个请求即可获取事件以从中重建对象，但是我们在数据库上并未使用NoSQL db。片刻，所以我在寻找替代品。

119 cqrs  event-sourcing 

让我们以一个简单的“帐户注册”示例为例，流程如下： 用户访问网站 点击“注册”按钮并填写表格，点击“保存”按钮 MVC控制器：通过读取ReadModel验证用户名的唯一性 RegisterCommand：再次验证用户名唯一性（这是问题） 当然，我们可以通过读取MVC控制器中的ReadModel来验证UserName的唯一性，以提高性能和用户体验。但是，我们仍然需要再次在RegisterCommand中验证唯一性，并且显然，我们不应该在Commands中访问ReadModel。 如果我们不使用事件源，则可以查询域模型，所以没有问题。但是，如果使用事件源，则无法查询域模型，那么如何在RegisterCommand中验证用户名的唯一性？ 注意： User类具有Id属性，而UserName不是User类的键属性。使用事件源时，我们只能通过Id获取域对象。 顺便说一句：在要求中，如果已使用输入的用户名，则网站应向访问者显示错误消息“对不起，用户名XXX不可用”。向访问者显示一条消息，例如：“我们正在创建您的帐户，请稍候，我们将稍后通过电子邮件将注册结果发送给您”，这是不可接受的。 有任何想法吗？非常感谢！ [更新] 一个更复杂的示例： 需求： 下订单时，系统应检查客户的订购历史记录，如果他是有价值的客户（如果客户在去年每月至少下达10个订单，那么他是有价值的），我们将为您减价10％。 实现方式： 我们创建PlaceOrderCommand，在命令中，我们需要查询订购历史记录以查看客户端是否有价值。但是，我们该怎么做呢？我们不应该在命令中访问ReadModel！正如Mikael所说，我们可以在帐户注册示例中使用补偿命令，但是如果在此订购示例中也使用补偿命令，它将太复杂，并且代码可能很难维护。

75 domain-driven-design  cqrs  event-sourcing  unique 

给定服务A（CMS）来控制模型（产品，让我们假设它具有的唯一字段是id，标题，价格）以及服务B（运费）和服务C（电子邮件）必须显示给定模型的方法是什么在事件采购方法中跨这些服务同步给定的模型信息？我们假设产品目录很少更改（但确实会更改），并且有管理员可以非常频繁地访问货运和电子邮件数据（示例功能为：B：display titles of products the order contained和C：）display content of email about shipping that is going to be sent。每个服务都有自己的数据库。 解决方案1 发送事件内有关产品的所有必需信息-这意味着以下结构order_placed： { order_id: [guid], product: { id: [guid], title: 'Foo', price: 1000 } } 关于服务B和C的产品信息存储在表的productJSON属性orders中 这样，为了显示必要的信息，仅使用从事件中检索到的数据 问题：根据需要在B和C中提供哪些其他信息，事件中的数据量可能会增加。B和C可能不需要有关Product的相同信息，但是事件必须包含两者（除非我们将事件分成两个）。如果给定事件中不存在给定数据，则代码将无法使用它-如果我们将给给定产品添加颜色选项，则对于B和C中的现有订单，给定产品将是无色的，除非我们更新事件然后重新运行它们。 解决方案2 在事件内仅发送产品的GUID-这意味着以下结构order_placed： { order_id: [guid], product_id: [guid] } 在服务B和C上，产品信息存储在表的product_id属性orders中 必要时，服务B和C通过对A/product/[guid]端点执行API调用来检索产品信息 问题：这使得B和C始终依赖于A。如果产品模式在A上发生更改，则必须对依赖于它们的所有服务进行更改 解决方案3 仅在事件内发送产品的GUID-这表示order_placed的结构如下： { …

10 microservices  event-sourcing