The context/why of events

[Alexandre Potvin Latreille]

What's the appropriate way to capture the context  in which events may have occurred or why they did? For instance, imagine a smart screening policy that could automatically reject candidates. We can assumed there's probably a `CandidateRejected` event, but what about capturing the reason why that happened?

Would it be better to generate a `SmartScreeningPolicyUnsatisfied(candidate)` right before the `CandidateRejected` event (in the same transaction). Perhaps we should add a `reason` to the `CandidateRejected` event? Could we just assume `SmartScreeningPolicyUnsatisfied` implies `CandidateRejected` (I guess not given the meaning could be lost over time)? Should we have a dedicated `CandidateRejectedBySmartScreening` event?

There's many ways to model this, but I'm just looking for some guidance and perhaps pitfalls to avoid?

Thanks!

[Tomas Ptacnik]

Hi Alexandre,

it's not easy to give advice without a deeper understanding, but with the info, you've provided I would say this: 

Simple is very often better so I suggest - publish only one event "CandidateRejected" with the field "reason=smart_screening"

But of course, there are many other ways how to design events in this situation and without knowing your solution and your domain better it's hard to give a proper advice. The other solution you suggested will also work.

One idea of how to validate which is better is to think about events consumption: Which event will be easier to consume.

Next though might be: which type of event is easier to extend.

Best

Tomas

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/90b61b29-0c9c-4c1e-a8c9-44df08f78d9bn%40googlegroups.com.

[Peter Hageus]

Perhaps a good way to reason is wether different reasons will trigger different behaviour in the system, or if it is just for informational purposes.

/Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/CAJ7md6VyFefZZ32QfNduDWAWt%3DufcsSWjgDQNJrxQVkOG5yU_Q%40mail.gmail.com.

[ste M33]

Very true, better to go for fine grained events if you find your switching the reason in the event handlers.

[mynkow]

Another option is to have  CandidateRejected event which contains a value object with the details IRejectionDetails, such as SmartScreeningPolicyRejection. Then you could capture the  CandidateRejected  and with strategy pattern to apply different logic if needed.

[ste M33]

You shouldn't leak value objects out of the domain inside events.

[Nikolai Mynkow]

It depends, for me it is perfectly fine to have VOs inside events because they never leave the bounded context. If I want to cross the boundaries I use published language.

Back to you again, Let's imagine that we have an event with VO. This VO has no meaning outside of the current BC, it is just data and other BCs will interpret the data in a random way. What problems did you face in the past doing this?

You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/TyLQRNPmWpM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dddcqrs/c508a916-01c5-4f2f-a169-3a4c59503a9bn%40googlegroups.com.