CODEWITHSUNDEEP
domain-driven-designbounded-contextsdomain-events
user644698
user644698

Reputation: 239

Domain event naming for things that haven't happened yet

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.

Upvotes: 0

Views: 153

Answers (3)

Phil Jackson
Phil Jackson

Reputation: 1

Although there is an event that happens when you have specified that someones job is 'going to' end lets call it "jobEndIntentionEvent", there is also an implicit event that happens when the persons job actually ends - "jobEndEvent".

Now, the source bounded context possibly doesn't need to raise this "jobEndEvent" to act on it itself. You may have multiple bounded contexts that are only really interested in knowing about this event though. So should it raise it at all? Or do the multiple other bounded contexts all have to play the cards they're dealt - i.e. listen for the "jobEndIntentionEvent" and implement code that fires when the event they would have liked to have heard ("jobEndEvent") would have been received?

Or should the origin bounded context be nice and fire this 'integration event' for everyone.

Or alternatively a nicer solution would be we have a scheduling bounded context that is a subscriber to "jobEndIntentionEvents" and similar ones to that, and it knows to convert them into the REAL events that people actually care about - "jobEndEvents".

Upvotes: 0

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57239

If the endDate is in the future, what would the domain event be?

JobCompletionScheduled?

We made the decision now, but it's effective date is in the future. That's a perfectly normal thing to do in a line of business, and the decision itself is useful business intelligence to capture.

Dig around with your domain experts, and listen closely - there may already be vocabulary in your domain that describes this case.

Upvotes: 0

Pedro Goes
Pedro Goes

Reputation: 726

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.

Upvotes: 2

Related Questions