I’m wondering if it wouldn’t be much better to schedule commands instead of events in Axon. Mainly for these two reasons:
First of all, scheduling commands would conceptually make more sense. An event informs listeners that something happened/changed in the application. However, scheduled events in Axon are generally used to affect change. Often a saga will listen for the event and dispatch a command. So most scheduled events today are already effectively used as commands anyway.
Secondly, scheduling commands instead of events could make the majority of sagas obsolete. Sagas are a necessary evil and will always serve as the ‘glue’ between different aggregates, but if we don’t need to involve sagas in scheduling anymore it would be a big win. In my own application 75% (12 out of 16) of my sagas are only involved in the scheduling of events followed by a dispatch of commands. If we schedule commands we could leave it up to e.g. the aggregate to do so without any serious drawbacks.
To make this more than a theoretical discussion I’ve built a proof-of-concept CommandScheduler that uses Quartz for scheduling and the Axon (XStream) serializer to serialize the commands. I also built and tested a basic example aggregate (not using event sourcing) that models a notification to users and uses the CommandScheduler. Attached are a bunch of source files:
- The interface and implementation of the CommandScheduler
- The basic example aggregate that uses the CommandScheduler
- Plus some classes that make it easy for command handlers to retrieve the ScheduleToken (if any) involved in the dispatching of the command
I would love to get your input.
CommandScheduleToken.java (1.94 KB)
DispatchCommandJob.java (3.21 KB)
QuartzCommandScheduler.java (7.11 KB)
QuartzCommandSchedulerFactoryBean.java (3.57 KB)
CommandScheduler.java (1.56 KB)
Notification.java (4.19 KB)