Don’t use the word reschedule
A DDD view of what a reschedule is
tl;dr Don’t use the word reschedule. It’s ambiguous so people get confused. If you are moving an appointment it’s easier to treat it as a cancel and new appointment
This article won’t cause world peace, or make you a million dollars. If you are designing or building a scheduling system it will probably save you at least a few hours of arguments and confusion over what a reschedule is and how to handle it. So overall it will probably save you time, which makes it a better deal than most articles on the internet.
I wrote this article after the third time I had a 15 minute conversation explaining the different ways people use the word reschedule. If I have to explain something more than a few times it’s worth the effort to write down the explanation. In this case business owners, product managers and developers were all using the word reschedule but it was not properly part of our Ubiquitous Language . Everyone had a different idea of what it meant.
Defining Reschedule
The word reschedule is too ambiguous to be used for anything where precision is required.
A human being can use reschedule in every day speech because in every day speech we don’t care about precision.
But if you need to speak precisely e.g. when programming a computer, looking at metrics, or designing a project, you need to define exactly what you mean. In every day speech a human being could reasonably utter the following sentences
“The 9:30 AM appointment is rescheduled to 9:45 AM.”
“The 9:30 AM appointment is rescheduled to 2:30 PM.”
“The 9:30 AM appointment is rescheduled. We haven’t decided when we’ll have it”
An appointment in these sentences is a meeting between (at least) two parties. Probably people. A tutor’s appointment, or an appointment to get your oil changed are the types of appointments I’m talking about. The three cases might be handled differently depending on what you care about.
Take the first case. If you have an appointment with you mechanic to get your oil changed at 9:30 and your mechanic finds out at 9:00 AM that the lift that he needs to put your car up on is going to be in use for the next 45 minutes the mechanic won’t call you to say they are running 15 minutes late.
The change in start time is so small that it is not worth informing you because it won’t change when you come in. However the mechanic may need to track when they started to work on your car for insurance or legal reasons, so they need to track the time change in their system. The change in start time is small enough that it is reasonable that only one party (the mechanic) know that the appointment has been moved.
The second case is different. Maybe the repair shop had someone call out sick or maybe the customer has a morning meeting that they can’t get out of. Either way the appointment start time has changed enough that both the mechanic and the customer need to know about it. For this type of reschedule both parties need to agree to the new time
If the two parties can’t agree on a new time to reschedule the appointment to this can lead to the third case. This case looks a lot like a cancellation. The only difference being that there is an intention to still have the appointment at some unspecified future time. In most cases though you can just treat them like a special form of cancellation. Even though a human would say that these are all “rescheduled” they are clearly different cases.
When you need to differentiate between the three cases you can call them delayed appointments, moved appointments, and cancelled appointments.
You need to call them different names because your software needs to handle them differently. Cancelled appointments are normally straightforward to handle. But with moved/delayed appointments you must also decide how to track the move/delay.
Implementing moving appointments
There are two ways commonly used to implement moving an appointment in software. You can update the time on the old appointment to the new time and (optionally) associate the old time with the history of the appointment. The other way to do it is to treat the old appointment as being cancelled and create a new appointment at the new time and add a link between them if needed.
An advantage of the former design is that you normally only care about the most up to date version of the appointment. The history of it being rescheduled is normally less used, mainly only for auditing. In addition from a DDD perspective if an appointment is an Entity, then the time of an appointment is just an attribute. Changing an attribute (start time) should not make a new entity (the appointment)
The advantage of treating a move as a cancel followed by a new appointment is that it is easier to implement and reason about. Every scheduling system already has the functionality for cancellations and adding an appointment. Moving an appointment is just combining the functionality. If you don’t need to track the history of an appointment it is a much simpler implementation. The downside is that if you want to measure cancellation then you need to distinguish between appointments that were “really” cancelled and appointments that were cancelled because they were moved.
Overall though if you don’t have another reason to track all the changes to an appointment it is generally a better idea to implement it using the second method. Besides being easier to implement it is easier to explain to non-technical people that “A move is cancel then a new appointment” than explaining your historical system
