Niclas, Rickard, I feel this as smth brillant. No more complex migration logic, UnitOfWork defining Commands and Events recording and delegating their processing to the domain ... I simply could not have thought about it ! :-)
Paul, waiting for more news on this side of the Qi (4J!) Le mercredi 22 juillet 2009 11:53:21, Rickard Öberg a écrit : > 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 _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
