Policy Questions

[Guilherme Soares Valdevieso]

Hi, Guys.

Happy to find this group! I would like to ask a question about Policies.

By definition: "a policy is a lilac rectangular sticky note, sitting in between an orange event

and a blue command."

My question is: Could a Policy sitting between N events and N commands or it could be a warning for bad modelling?

I'm asking this because we made some EventStorming session in the past and for each event triggered we've created a Policy and in my opinion, this policies could be grouped in a single policy.

Thank you!!

[Wojciech Żdżarski]

Hi!
I don't feel eligible to answer your question, but in my opinion it depends on the fact whether the details of events and commands that are merged to the single one are valuable for the domain.

Is your concern presented in the picture above?

[Guilherme Soares Valdevieso]

Hi, thank you so much for your response!

Yes, you represented well my question.

My main concern is about the 1 Event x 1 Policy x 1 Command rule.

Could I have one policy for any "poured" event  ("whenever a hot water is poured ...") or this is not right?

Thank you again!!

[abaddon]

Hi all,

Nice question, could be possibile that the problem in your case is related to the business logic / aggregate block? I mean if you have 3 different events like cappuccino poured, caffe poured etc.. my expectation is to have 3 different blocks that fire these events. An aggregate related to the coffe and an aggregate related to the cappuccino etc..

If you have only one aggregate called “drink” in this case the right event could be drink poured and the type of drink could be an attribute of the aggregate. 

Following this approach you will have in both cases one policy for each event triggered.

Best,

Stefano 

--
You received this message because you are subscribed to the Google Groups "EventStorming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventstormin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eventstorming/51bd1a95-8fc3-443e-ac4c-dc2f113cb51cn%40googlegroups.com.

[Alberto Brandolini]

Hi Folks!

... there is not a rule stating that only one event can trigger a policy or that a policy cannot emit more than one command.

Can a policy be triggered by more than one event? Yes, quite often the same policy will be listening to complementary actions: think about an aggressive reservation policy listening to both ItemAddedToCart and ItemRemovedFromCart. 

The same example could fit also the question regarding can the same policy trigger more than one command? Once again yes, not a strong rule.

but... is a single policy triggering many commands a smell? Yes... especially if the commands are directed towards different bounded contexts.

keep in mind that EventStorming should promote an interdisciplinary conversation without getting into too technical discussions, but the concept lurking in the background is related to roles/responsibility assignment, coupling and cohesion, orchestration vs choreography, and so on. A single policy doing many things is a possible design smell. I prefer having many smaller ones, to eventually merge if I see they're based upon the same reasoning.

One more interesting weapon to use is to check the flow with other scenarios and see which steps of the policy are affected and which are left the same. If they're changing for different reasons, maybe they're part of smaller independent policies.

But ES is not intended to tell you which direction is better. It's intended to force you to have the right discussion. So maybe try both approaches and choose later is the right answer.

Alberto

To view this discussion on the web visit https://groups.google.com/d/msgid/eventstorming/CACaAbCVAXJBAY8EEddwmcF%2BoJPP47eKFeL2pKNurCsFm3oeJog%40mail.gmail.com.

--

Alberto Brandolini
Phone: +39-347-6005027

E-mail: alberto.b...@gmail.com
Twitter: @ziobrando

Company: http://www.avanscoperta.it
Blog: http://ziobrando.blogspot.com
Linkedin: http://www.linkedin.com/in/brando