Think about a JavaScript 2D platform game. There are tons of different components interacting with each other on the screen, all at the same time. There's a component that indicates the number of lives remaining, another one that shows all the points scored, and another one counting down the time remaining to finish the current level. Each time your character jumps on an enemy, the points increase. When your scoring goes higher than a certain number of points, you get an extra life. When your character picks up a key, a door usually opens. But how do all these components interact with one another? What's the optimal architecture for this scenario?

There are probably two main options: the first one is to couple each component with the ones it's connected to. However, in the above example, that means a lot of components are coupled together, with each new addition requiring the developer to modify the code. But do you remember the Open Closed Principle (OCP)? Adding a new component shouldn't make it so the first component has to be updated; this would be too much work to maintain.

The second — and better — approach is to connect all the components to a single object that handles all the important Events in the game. It receives Events from each component and forwards them to specific components. For example, the scoring component would be interested in an EnemyKilled Event, while the LifeCaptured Event is quite useful for the player Entity and the remaining lives component. In this way, all components are coupled to a single component that manages all the notifications. With this approach, adding or removing components doesn't affect the existing ones.

When developing a single application, Events come in handy for decoupling components. When developing a whole Domain in a distributed way, Events are very useful for decoupling each service or application that plays a role in the Domain. The key points are the same, but on a different scale.