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.

事件处理数据的变化，代码的变化呢？ 我们可以将这里视为三种广泛的代码更改：新功能、缺陷修复和时序逻辑。

构建事件处理程序逻辑

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

This was great for passing things between services where fire-and-forget was adequate.

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.

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.

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.

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.

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.

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.

One alternative would be to have one topic per entity