The ability to delay sending messages into the future is a very powerful pattern when we start talking about messaging based systems and is often a useful way of dealing with temporal problems, Greg Young explained at the recent DDD Exchange conference in London.
Greg, who coined the term CQRS, gives an example of this type of problem; scheduling of things to happen in the future. A common solution to this is a batch job that will run a query on the domain model and then update some aggregates, but domain experts normally don’t talk about batch jobs, more often it's about about scheduling and things that happen in the future because of scheduling today.
An alternative way of modelling this kind of problem that Greg often prefers is to raise a message and say that it should be delivered at some point in the future. A common way to do this is for an object to put its state in a message and then tell the system to deliver the message to itself sometime in the future, a common use case being timeouts, This pattern actually removes the time problem because what matters now is the order messages are received, not when they are received.
From a domain modelling perspective we end up with a completely different model and can talk with domain experts about behaviour and scheduling behaviour into the future, not about queries and batches and many domain experts are comfortable with this. A potentially important difference between a typical aggregate model and an event based model is that in the aggregate model a query is required to resolve the state, if no query is made the state may be incorrect. In an event model the state is always correct.
Greg ends by stating that there are a lot of problems where time is a real domain concept and event based modelling fits these temporal problems much better than using aggregates and a flat current state model because we are explicitly modelling the temporal aspects of the domain through the concept of delayed messages into the future. He notes though that this is not a solution for every problem but there are situations where this type of solution fits very well.
Next year’s DDD Exchange is scheduled for 19th June 2015 and registration is open.