According to Vernon Vaughn's - Implementing Domain Driven design:

...Events are used to rebuild the state of the Aggregate by replaying them in the same order in which they occurred. The premise is that this approach simplifies persistence..

My question is... In a DDD system where your domain is publishing events (and those events published to an event store), but the aggregates themselves are still persisted to a relational database - does the benefit of replaying events to create/recreate new readmodels come from simply having an event store? or do you need an event sourced domain (i.e having a version/sequence) to guarantee replayability.

1 Answer 1


Event Sourcing is the process of rebuilding state (usually of an Aggregate in the command model) based on its past events, rather than a stored representation of its state. Rebuilding a view model merely requires you to be able to reproduce the events that we published "at the time".

So essentially, these are different processes and one can work without the other. Practically, it means you should store the published events somewhere, to be able to "replay" them to a specific component. Whether those events are also used to reconstruct your aggregates isn't important.

  • Thanks @Allard, that has clarified some things for me. Looking at the feasibility of an interim 'RDBMS aggregate persistence + events published to an event store', but requiring the benefit of creating new read models. Also, I enjoyed your talk yesterday! Oct 18, 2017 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.