Niclas Hedhman wrote:
Rickard and I had a fruitful brainstorm sessions yesterday, and I
thought he would post information about the result.
I was in the process of posting it, but was awaiting responses from the
DDD mailing list as I posted there first. Oh well.
So, what are we saying?
With a correct setup of Event (or Command) recording, it is possible
to restore the Entity Store state. If you use the suggested
event/command system, it is recommended that you consider the
EntityStore a "snapshot" of the current state, and the real state is
recorded as a sequence of events in the domain model. Hence, the
"snapshot" may be zapped, playback the event log and you will have the
EntityStore snapshot back with same values.
The essence here is that the data snapshot of your model is not the key
value. Whenever you change the model, you would typically perform data
migration, and sometimes this is possible, but in any non-trivial case
it is simply not possible at all.
As an example, that I posted on the DDD list: if I have an Organization
entity which I can call a command to do "newProject", then if the
command succeeds it will result in the event "projectCreated(id:1234,
org:5678)" to be created. In v1 of the model this might add the new
Project to a ManyAssociation in the Organization, so that we can list
Projects of an Organization. In v2 of the model we might introduce a
backpointer from Project to Organization. In v3 of the model we might
add a counter in the Organization of how many projects are available.
And in v4 the counter might be split into one counter for active
projects and another for completed projects.
All of these changes would be more or less impossible to do using
traditional data migration (i.e. alter table-style), since they involve
domain rules that have changed significantly. However, if we store the
event "projectCreated(id:1234,org:5678)" then we can simply replay this
against the model, and the v4 domain model will create the appropriate
state that we need. All we had to do was throw away the database and
replay the events. At no point do we have to be afraid of making
"radical changes" or create "migration schemas" or somesuch. As long as
the events can be consumed by the new model it will "just work".
This does require that event logs are stored from day one of the system,
and can be replayed later on. This might involve a lot of data after a
couple of years running. But, I think this can be handled through
archival rules in many cases. So, instead of creating migration scripts
we would create rules for filtering out what events we need to keep in
order to be able to recreate the system. This should be a lot simpler
than trying to make a generic data migration API that won't handle
anything but the simplest cases anyway.
That's the general idea. Any thoughts on this?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
