Have you ever heard phrases like.
\n\n\nJust an update, the milk ran out. Someone finished it and put the empty carton back.
\n
Or
\n\n\nSo everyone is aware, the meeting started 15 minutes ago.
\n
Or
\n\n\nHeads up: the coffee machine is empty again.
\n
Or
\n\n\nIt’s fine, I already walked the dog.
\n
I’m sure you either heard or used such phrases.
\nWe all know that there’s some intention behind it.
\nThe intention is not to inform, but to trigger some action.
\nFormally, we’re reporting on events to announce the facts, but in practice, they’re passive-aggressive words. The real intention is to command someone.
\nWe don’t want to inform you that the trash bin is full, but we want someone to take it out. We don’t want to inform you that the coffee machine requires a coffee bean refill, but we want someone to do it.
\nPassive-aggressive tone is the worst. It’s toxic for both sides of the communication. Usually, it’s just better to ask someone to do it.
\nThe same rule also works in Event-Driven Modelling. We should avoid passive-aggressive communication at all costs.
\nWe should watch out for Passive-Agressive Events. So events that should be commands.
\nI already warned you in past: don’t let Event-Driven Architecture buzzwords fool you.
\nEvent-Driven Architecture is an integration architecture style. We’re trying to model our business processes so they run smoothly. For that, we prefer a non-blocking communication flow, with things happening in parallel at their own pace. The goal is to achieve autonomous components that reduce the time needed to understand them. That helps maintain, or even replace them as your business evolves.
\nAnd events are enablers for that. They notify of what has happened, allowing other components to interpret facts and take the next steps.
\nBut… Let me show one more photo.
\nThrough my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.
\nSome time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.
\nMany people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.
\nMany seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?
\nThe end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.
\nI believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.
\nAfter I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?
\nPeople usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).
\nThe truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.
\nTherefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.
\nPolish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.
\nCheers!
\nOskar
"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/passive_aggressive_events/","lang":"en","langKey":"en","prev":{"id":"759c3674-3d52-5530-a074-502fbe9fab4a","fields":{"slug":"/intro_to_example_mapping/","prefix":"2026-03-30","source":"posts","langKey":"en"},"frontmatter":{"title":"The one where Oskar explains Example Mapping","category":"Software Architecture"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}