I'm focused on developing and expanding my knowledge and skills. Enjoying new challenges. I'm assuming that there are no stupid questions, there are only silly answers.
It’s a lovely article describing the capabilities of MediatR. A thing that could interest you is the term “bounded context” introduced in Eric Evan's book. Also, a very underrated topic related to the bounded context is called “context map”.
In your example, I see two contexts: ordering and scheduling. Both are separated. That is why it makes sense to implement the logic in separate handlers. You introduce an event called “OrderPlacedEvent” in the Ordering context that has a side effect in the Scheduling context. The dependency between that two contexts could be reverted. A “ThingScheduledEvent” could make the job done. Now the The scheduling context is an “Upstream” context, and we could schedule things from other places without any change the handler is responsible for scheduling.
It’s a lovely article describing the capabilities of MediatR. A thing that could interest you is the term “bounded context” introduced in Eric Evan's book. Also, a very underrated topic related to the bounded context is called “context map”.
In your example, I see two contexts: ordering and scheduling. Both are separated. That is why it makes sense to implement the logic in separate handlers. You introduce an event called “OrderPlacedEvent” in the Ordering context that has a side effect in the Scheduling context. The dependency between that two contexts could be reverted. A “ThingScheduledEvent” could make the job done. Now the The scheduling context is an “Upstream” context, and we could schedule things from other places without any change the handler is responsible for scheduling.
Thanks a lot for your feedback!
I didn't knew about the terminology, I will definitely check it out, it makes even more sense with a name on it!