I read a very interesting article yesterday. We are busy with a POC on this and will probably be implementing this on one of our big projects coming up.
The idea is that you have a domain model that is based on state. This state comes in from one or more input sources. These input sources generate events that come into your system. These events get routed to your EventLog.
The EventLog has three purposes:
- It persists all events it receives (in order) to some repository (in memory, database, etc).
- It generates events based on the incoming events and forward the events to the EventProcessor.
- On startup, it will get all available events persisted from the repository and reconstitute the state of the domain.
The EventProcessor propagates the events throughout your domain model.Once the domain receives the events, additional events can be triggered based on domain change. These events get routed to one or more output sources.
What this gives us is that the domain model is completed driven around events. This is especially usefull when working in a publish/subscribe model where your system is receiving broadcast messages (like order price change) from a broadcaster. Only the relevant data is pushed to your system. Because we have a complete log (in order) of events in a repository we can provide rollback or playback functionality. If the system dies for some reason, on startup the domain will reload itself from the repository and be in the correct state because the order of events were persisted.
A very interesting model to adapt when working in a messaging system.