Okay, I appreciate the title sounds odd. An event should always be for something that has happened, e.g. OrderCreated, ParcelShipped, etc.
However, I wonder if anyone has any thoughts on the following problem.
Consider an HR application which models people and their jobs. For simplicity's sake, a person can have a bunch of jobs and they can be ended at a date. The person has an EndJob operation which takes an endDate.
If the endDate is in the future, what would the domain event be?
JobEndedEvent (this is not true)
JobEndDateAddedEvent (this is quite technical)
Consumers in other bounded contexts will be interested to know that the Job will be ending, but may also wish to be informed at the point the job ends as well. I feel that the latter should be the consumer's responsibility, rather than the source's.
Any thoughts would be welcomed... Thanks.
Well, from a Domain perspective, you're probably talking about JobTerminationScheduledEvent because from the language point of view, you're notifying other contexts about a scheduling of a job's ending.
It's not the actual thing, schedulings can change and you will leave up to the other contexts how will they handle such an information. A given context might consider the scheduling to be enough information to consider the job will end by the given date.
Another context, as being notifying that such an event happened they might want to double-check when the date comes to make sure no changes happened before taking further action.
In the end, your context is actually expressing what happened which is: nothing concrete. You have a scheduled date defined for this action to happen, but it didn't happen yet.