12 Matching Annotations
  1. Feb 2023
    1. Event Replay: If we find a past event was incorrect, we can compute the consequences by reversing it and later events and then replaying the new event and later events. (Or indeed by throwing away the application state and replaying all events with the correct event in sequence.) The same technique can handle events received in the wrong sequence - a common problem with systems that communicate with asynchronous messaging.
  2. Jul 2022
    1. 事件处理数据的变化,代码的变化呢? 我们可以将这里视为三种广泛的代码更改:新功能、缺陷修复和时序逻辑。

      Event Source的挑战,除了与非事件溯源的系统交互即外部互动(含外部更新和外部查询),还包括代码的变更本身。主要设计 时序逻辑的调整、bug fix 和 新 feat 开发

    2. 构建事件处理程序逻辑


    3. Complete Rebuild:我们可以完全丢弃应用程序状态并通过在空应用程序上重新运行事件日志中的事件来重建它。 时间查询:我们可以在任何时间点确定应用程序的状态。从概念上讲,我们通过从空白状态开始并将事件重新运行到特定时间或事件来做到这一点。我们可以通过考虑多个时间线(类似于版本控制系统中的分支)来进一步实现这一点。 事件重播:如果我们发现过去的事件不正确,我们可以通过反转它和以后的事件来计算后果,然后重播新的事件和以后的事件。(或者实际上是通过丢弃应用程序状态并按顺序使用正确事件重播所有事件。)相同的技术可以处理以错误顺序接收的事件——这是与异步消息通信的系统的常见问题。

      通过对事件的记录,我们可以完全的将历史重现,也可以查询特定时间点的程序状态。历史的部分重现也可以用于debug。 典型代码就是VCS,git保留了项目开发的完整历史。

  3. Jan 2022
    1. This was great for passing things between services where fire-and-forget was adequate.

      In which cases, "fire-and-forget" is not adequate?

  4. Nov 2019
    1. The second type of these “Imperative Shell” services execute side-effects outside of the bounded context, such as sending an email, SMS, or mobile push notification to a user, or calling out to some other external service.

      What if the bounded context is about managing side effects — say we are implementing a transactional mail service. Should we separate the “functional core” recording mail processing events from the “imperative shell” which performs the actual SMTP?

  5. Sep 2019
    1. Independently on how the schema changes are handled, managing these changes is one of the most complex and error prone drawbacks associated with event sourcing. A strategy should be prepared upfront and considered on the system design.

      Plan for schema evolution upfront.

    2. Also your events will be based on a SomethingCreated or SomethingUpdated which has no business value at all. If the events are being designing like this then it is clear you’re not using DDD at all and you’re better of without event sourcing.

      litmus test

    1. I think you don't hear much about using Kafka for event sourcing primarily because the event sourcing terminology doesn't seem to be very prevalent in the consumer web space where Kafka is most popular.
    1. Another way to get consistency is to assure serialized writes, i.e using the single-writer principle, meaning we make sure all writes concerning a particular entity ID occur on a single thread.

      This is the akka-cluster approach?

    2. If the business logic fails we return an error to the client but if it succeeds a new event is emitted. In that case we must be able to save the new event to our event store with a guarantee that no other event has been stored for this particular entity ID in the meantime, or we would risk breaking the consistency of our domain objects.
    3. One alternative would be to have one topic per entity

      Other alternative: have a consumer group write a read model to a database, indexed by entity id.