在事件源中快照为域事件
我在我的事件源模型中有一些非常恒定的聚合，它们将积累大量的事件。我正在考虑使用快照来优化这些集料的再水合。即。集料是仓库。
编辑：标题和--这个评论似乎建议将快照作为域事件是错误的方法。
编辑2：简化问题-将回购注入命令处理程序是否合适？
共有1个答案
让我先攻击容易的那一个。快照逻辑不属于聚合中。是否shapshot以及何时shapshot纯粹是一个性能问题，因此不属于业务规则。它有助于通过想象一个拥有无限资源的服务器来画出这条线。如果你不需要在这台神奇的机器上做“事情”，“事情”就不属于聚合体。
在上面发布的链接中，我同意RBanks54的观点，即快照不属于聚合事件流，因为他列出了所有原因。我认为您的解决方案是在服务总线上分派一个事件，然后在不同的命令中处理该事件，这是正确的方法。在处理新事件的上下文中处理快照意味着除非接收到新事件，否则无法进行快照。在服务总线上有一个不同的消息意味着任何进程都可以在适当的时候请求快照。
-
具有事件源的CQR看起来非常适合作为我们的一个系统的架构，目前我们只担心一件小事：处理大量事件，并因此处理大型事件商店。 我们当前的系统每天接收大约一百万个事件（目前与事件源无关），如果我们将它们存储在更长的时间内，我们的事件存储可能会变得相当大，但是如果我们经常转储/清除滚动快照，我们可能会失去事件源的一大优势：关于系统历史和重播的信息。 在CQRS架构中处理这个问题的常见方法是什么？这到底是个
-
问题内容： 我正在尝试使用SSE将JSON数据发送到浏览器，但似乎无法正确处理，而且我也不知道为什么。 服务器端看起来像这样： 如您所见，我已经注释掉了帖子内容，但最终我希望将testdata用作JSON本身，如下所示： 客户端看起来像这样： 我看到控制台日志，但 没有看到警报。 问题答案： 尝试发送适当的JSON（输出中未引用）： 但最好：
-
这个问题类似于将Kafka用作CQRS EventStore。好主意？，但更具体的实现。当我有数千个事件“源”（DDD中的聚合根）时，如何使用kafka作为事件存储？正如我在链接问题和其他一些地方读到的，我会有每个来源的主题的问题。如果我将事件按类型拆分到主题中，它将更容易使用和存储，但我需要访问特定源的事件流。如何用Kafka做事件来源？
-
我是事件采购的新手，但对于我们当前的项目，我认为这是一个非常有前途的选择，主要是因为审计跟踪。 有一件事我不是100%满意，那就是缺乏跨聚合的超越。请考虑以下问题： 我有一个订单，它在不同的机器上处理，在不同的车站。我们有集装箱，工人们把订单放进去，然后把它从一台机器运到另一台机器。 必须通过容器（具有唯一的条形码id）进行跟踪，订单本身无法识别。问题是：容器是重用的，需要锁定，因此没有工作人员可
-
3.6 ABP领域层 - 领域事件 在C#中,一个类可以定义其专属的事件并且其它类可以注册该事件并监听，当事件被触发时可以获得事件通知。这对于对于桌面应用程序或独立的Windows Service来说非常有用。但是, 对于Web应用程序来说会有点问题,因为对象是根据请求(request)被创建并且它们的生命周期都很短暂。我们很难注册其它类别的事件。同样地,直接注册其它类别的事件也造成了类之间的耦合
-
我在CQRS/ES设计中有一个计时案例。为了便于讨论，让我们以Microsoft关于这个主题的示例会议管理为基础(https://msdn.microsoft.com/en-us/library/jj554200.aspx)。 假设在第1分钟创建会议（最大座位数为20）。 在第4分钟，事件到达order mgmt上下文，因此创建了一个座位可用性。 在第7分钟，用户下了一个订单（通过订单管理），购买