avatarAlberto Brandolini

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

791

Abstract

just go on!</li><li>I have a problem with the term ‘Business Rules’. It’s apparently obvious <i>“everybody knows what a business rule is” </i>but everybody’s understanding is different. So I just don’t use it.</li><li><i>Policies</i> and <i>Aggregates are different</i>, on a few specific things. During the exploration, yellow aggregates tend to behave like units of consistent behaviour (triggering some OO-thinking in terms of responsibilities), while lilac policies are my <i>lie detectors</i>: policies can be <i>rules, agreements, conventions, habits, implicit or explicit, followed or ignored</i> and they sparkle a much different conversation. Policies can also usually cross bounded contexts <i>when one thing happens in ‘sales’ we send a signal to ‘fraud detection’ </i>while aggreg

Options

ates are intrinsically local.</li><li>Colours and shapes help me. :-) Yellow and Lilac produce some kind of visual <b><i>symmetry</i></b> and the lack of it will be a signal, that something is not completed. The shape of the model (Lilac and Yellow are also <i>larger</i> for the same reason) would tell me something, like <i>this state is changed here, but never really reversed or completed</i> without even reading the stickies, it’s the shape of the flow that doesn’t click! If you’re not taking advantage of it, feel free to change (see point 1) but …yep <i>I had good reasons for my colours.</i></li></ol><p id="781c">Point 1 is probably the most important. I don’t care about orthodoxy or doing things <i>in the right way</i>. But I can’t stop having opinions too!</p></article></body>

Hi Martin, I was not in this specific discussion during this summit. I guess it was the one I jumped onto later… ;-) but now I understood better a couple of things. So here are my thoughts.

  1. Many people view EventStorming as a way to blueprint Event-Driven software, but I am seeing it more and more as a platform for facilitating a more sophisticated conversation about software. I have recipes for that — The Picture That Explains Everything — that also reflect the way I see software. That recipe works well for me (and me is an active part of de modelling activity), but it’s not a dogma: if you find a combination of building blocks that shapes the conversation in a way which better suits you and the current audience, just go on!
  2. I have a problem with the term ‘Business Rules’. It’s apparently obvious “everybody knows what a business rule is” but everybody’s understanding is different. So I just don’t use it.
  3. Policies and Aggregates are different, on a few specific things. During the exploration, yellow aggregates tend to behave like units of consistent behaviour (triggering some OO-thinking in terms of responsibilities), while lilac policies are my lie detectors: policies can be rules, agreements, conventions, habits, implicit or explicit, followed or ignored and they sparkle a much different conversation. Policies can also usually cross bounded contexts when one thing happens in ‘sales’ we send a signal to ‘fraud detection’ while aggregates are intrinsically local.
  4. Colours and shapes help me. :-) Yellow and Lilac produce some kind of visual symmetry and the lack of it will be a signal, that something is not completed. The shape of the model (Lilac and Yellow are also larger for the same reason) would tell me something, like this state is changed here, but never really reversed or completed without even reading the stickies, it’s the shape of the flow that doesn’t click! If you’re not taking advantage of it, feel free to change (see point 1) but …yep I had good reasons for my colours.

Point 1 is probably the most important. I don’t care about orthodoxy or doing things in the right way. But I can’t stop having opinions too!

Eventstorming
Ddd
Software Design
Business Rules
Software Architecture
Recommended from ReadMedium