I got this great question in one of my comments:

Modeling the entire history of the domain seems to only be valuable if the domain requires it as part of your domain? I guess the biggest concern with a pattern like this would be how you would effectively deal with different versions of code that have existed at different points along the path. The report one would generate from 10 releases ago might not be the same if you are reapplying events as you go. This could certainly have business implications too, how do you suggest dealing with this?

If the the application of an event changes, do you simply create new events and never modify old ones?

I will try to answer some of it:

Storing the entire history
It’s not so much the domain that usually requires you to keep the entire history, but you keep it for auditing. If you only keep your current state in your database, how do you know that the data is correct ? Anything could have happened to keep it from being correct, like bugs and evil people :) With an add-only model you even have the possibility of writing the events to a write-once-storage. Now it is impossible to manipulate the data. If you write a bug that creates false events, you would later execute compensating actions to undo what you did. Remember that an event is something that  has happened (past tense) so it makes no sense to change it in any way.

There is another good reason to keep the history as well. When saving events you are not saving data to your current data model, but you are actually storing all the user behaviour. If you only store the current state of the domain, the reporting you can do on this data is limited. The information stored in an add-only model is much richer. You can do reports on things you didn’t event think of when you created the application.

Versioning
If your events changes you would create a new version of that event, and  keep the old ones. To keep your domain code form being bloated with handling of all versions of  events you would basically introduce a component that converts your events from previous  to newer versions, and then apply them on the domain. Remember that events are things that actually happened in your domain so in most cases the information in deprecated events are valuable.

That said, there are of course situations where you would choose different architectural patterns.

F Share