On Wed, Jul 22, 2009 at 18:31, Rickard Öberg<[email protected]> wrote: > SMS notification and building up a model snapshot are both examples of > handling events caused by commands. When you are recreating the snapshot you > are therefore not recreating the events, just playing them again. The SMS > notification should not be done by the model itself, but rather something > external that also listens to the events (i.e. the domain model and the SMS > notification are both consumers of events). This way there is no risk that > replaying the events to create the snapshot does anything but that. > > But this needs to be kept in mind when creating the domain model, so that > things like SMS notification are not accidentally built into the domain > model itself, but rather kept outside of it.
Agree on this. IIUC, this implies that there must a way to distinguish which event handler should be invoked during replay. > The simple rule is that the domain model cannot use any services, and > therefore is not able to call the SMS service. The only thing it can do > is build up the state of the domain model. Ok.. I can't think a single use case that breaks this rule atm. Does this mean we're going to enforce this? Any entity mixin must not have @Service declaration? >>> Commands are methods on Entities. >> >> Entity can be created and deleted. >> If command are methods on entities. >> Who will handle the "creational" command? > > Good question. My current take on that is that one will have to create a > root entity with a given id when the system is started, so that there is > always something that can be used to create the new entities. > > But this might be entirely wrong. It might be that command execution is > something entirely separate from the entities themselves, i.e. should be in > services or similar. Another thing that I noticed If we look at DDD sample, where a routing service doesn't belong to any entity. How should we model this "routing" command? >>> 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. >> >> As long as we don't deal with "remote" service? >> Can replay be orchestrated with remote qi4j application? >> This is probably a non-concern atm. > > Not sure what you mean here. Can you clarify further? Nvm about this :) If we have a simple rule entity must not use any service. Each application will be isolated, even if there's a integration between application A and B. This integration aspect is irrelevant during migration. one additional question: How do we migrate eventV1 -> eventV2? That way in v1 -> v2 -> v3 We don't have to redo v1 -> v2 migration. Hence, eventually we can take these old migration code out from the code. Note: In this case event is not an audit record. Regards, Edward Yakop _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
