Earlier, I posted a question about how to test scheduled events.
I now realize I can’t answer a more fundamental question: what should motivate me to use events vs deadlines, for example to schedule future activities.
I am working on an application that needs to
- schedule activities for its users based on some business rules
- remind the users to perform these activities at specific predefined times
- record the time the user took responding to the reminder
- have some other system score user’s behavior and perhaps give them money as a reward.
I modeled application user as an aggregate root User. Among other things, I made it responsible for creating user activity schedule as it has all the knowledge to do it. I would also like it to trigger notifications, to be acted on by some external event handler that knows the notification machinery.
- schedule an event to be published at the time the user needs a reminder
- schedule a deadline to come due at the time of reminder to publish that event immediately
My current incomplete understanding:
Deadlines seem to fit well in the narratives like “whenever the customer has not submitted their application in 30 days…” or “whenever the invoice has not been paid by the 15th of the month”. Sounds like event storming policies.
These narratives feel natural for describing long(-ish)-running business processes expecting that an external actor does something by a certain time, defining the policy to use if the actor has not done so. In other words, the literal meaning of “deadline”.
Also, these kind of processes are convenient to model with sagas.
I could choose deadlines to represent reminders, setting up a saga for the duration of the schedule, complete with a deadline for each reminder. The saga would then emit commands to User when a deadline elapses… Doesn’t sound right as I don’t need to coordinate this across multiple aggregates, plus unnecessary moving parts.
Should I then have my User aggregate set up a bunch of deadlines for itself, in command handler responding to the command telling it to create the user’s schedule? Then, in deadline handler, I could publish an event to trigger a reminder every time a deadline comes due.
Events, on the other hand, feel to me more natural to use as a scheduling mechanism for (shorter-term?) reminders, timers, recurrent activities: “remind the user do take their blood pressure meds at 9:00am every day”. Notice the absence of not: we have a business process requiring something to happen at a regular time as opposed to no later than…. Not a policy.
I am tempted to schedule user activities for the known future in the appropriate command handler as events. Then, whenever such event is published, my aggregate will take note, and once the user responded to the reminder, it will publish another event telling the interested parties how long the user took to respond.
That’s where doubt creeps in: is this a misuse of events? One sign of this is the difficulty naming such events: UserReadyToBeNotified? NotificationRequested? Should I just publish the schedule and have some other component, unrelated to the user, do all the scheduling?
To pick a scheduling mechanism appropriate for my situation, I would like to know how the authors of Axon Framework intended to use deadlines vs scheduled events. I have not been able to find a good answer either in Axon documentation or on this forum.
- what kind of scenarios are better served by deadlines?
- what kind of scenarios are better served by scheduled events?
Thank you very much,