Here are the contents of my talk in the 3d DDDBarcelona meetup, the 8th of November. It was an excellent occasion to learn about the experiences with DDD of other fellows in the audience, as well as learn from the other two speakers: Aleix Morgadas, who talk about Adopting DDD in the teams, and Daniel Solé, who introduced us to the techniques of Domain Storytelling.
My talk was about how possible it may be to reproduce knowledge about the Domain from an Event Storage. However, and for a better understanding of the topic, I thought that a brief introduction might be helpful. You have the slides and video below.
Events
Events are representations of Facts, and Facts are those petty pieces of external reality such as A Customer purchased 3 units of Item A for 15.99€, for instance.
In other words, facts are taken as atoms of truth. Hence actual facts might be wrong (i.e. that did not happen that way, or did not happen at all), but they cannot be false.
For software production purposes, facts are the atoms of truth.
That truth is carried over to the Domain by making Events immutable: once they are dispatched, Events stay readonly.
Events map Facts to the Domain, meaning that they express facts with the words of the Ubiquitous Language, which is the language the Domain can talk.
In that sense, Events are not neutral. As any other representation, some details from the Fact are taken, and translated, into the Events whereas other details are ignored.
State
Events bring change into the Domain by triggering Commands, Application Services, or Domain Services to run. From the point of view of the Domain, this change is perceived as modifications in the values of properties of some Entities, as the creation of new instances of some other Entities, or the removal of instances of other Entities.
These changes in the Domain details triggered by Events allow us to define States.
A State is any summary of the values of some properties of Entities at any particular moment in time
There is no restriction on what kind of States we may define. In Finance and Accounting they are being dealing with States for years, even centuries: Profits and Losses, as well as Balance Sheets, are States as we just defined them.
Example: inventory
Provided Events bring change into the Domain, it looks like a healthy measure for data consistency (i.e., to ensure that every change in data is traceable) to reverse the scenario and set that no change in the Domain should happen unless triggered by some Event.
No matter how hard this goal might look, it is not impossible: Accounting stands as the proof that it is possible, thanks to a very short list of States to keep an eye on, and an Event storage (in this case, the ledger books) filled under very strict a set of rules.
State Recovery
So, provided that every State was triggered by Events, we should we able, in theory, to rewind and rerun Events from start and up to any specific point in time and produce any State exactly as it was then.
Trouble comes when we have to deal with either uncompleted, or mistaken information. Is it possible to fix the past, i.e., to act retrospectively on States? Being the Events immutable as they are, how could we, for instance, modify right now a State referring to yesterday 8:00pm?
This was the topic of my talk, which I hope you’ll enjoy.
how possible 
Leave a Reply