3 ms·
I think the move to events makes sense once you want to start decoupling systems, so there is a scale/complexity aspect to it. Situations where you would steer
by sfrensch 5y ago
I think the move to events makes sense once you want to start decoupling systems, so there is a scale/complexity aspect to it. Situations where you would steer clear of events, would be those where you don't care to have the benefit of decoupling.
As an example, imagine a small system where a user changes their email address. In the beginning you might only have one action "update database". As the system grows, maybe new teams start to add new features triggered from that event, say "send confirmation email", "calculate fraud score", "send new email to marketing vendor". You could just go and call all those APIs, but at some point you want to emit a "change email event" and just let the other systems do with it what they will.
- sorokod 5y agoI often see this sort of argument and disagree. The complexity is still there but instead of being someone's problem, it's owned by no one.
- busterarm 5y agoThat's an organizational problem, rather than a software architecture problem. Refer to the first 3 bullet points of the Bezos Mandate.
- sorokod 5y agoDepends on your definition of "organisational" but note that it is the architecture that converts one to the other. In fact it is this that makes event driven so attractive, rather the solving a difficult problem right now, someone will need to sort out the mess later.