Who calls who? — a simple events heuristic

When integrating two components, you may wonder who should own the commands and events you want to use for communication. Today, I will show you a simple heuristic that may help you make this decision. The heuristic relies on the frequency of change in components. Before using it, we should visualize relationships between those components. Context Mapping is a perfect tool for that, as it shows how changes in one Bounded Context affect others (there is an excellent resource about the concept itself here).

And now, without further ado, let’s jump into an example. Let’s assume that we have two components: Registration and Payment. Registration component changes a lot (green dots below mean a single change), as it has some rules that can change. On the other hand, Payment component rarely changes.

Now let’s assume we decided to communicate between those components using commands/events (interfaces) from the Registration:

It means that by doing that, we also defined the upstream-downstream relationship between those components, where Registration is an upstream:

It also means there is a bigger chance that changes in the Registration will cause some changes in Payment. There is a higher coupling between those two components. To make it looser, we should change the direction of the upstream-downstream relationship. We can do it by simply using commands/events from Payment like this:

It’s worth noticing how the names of interfaces changed based on which component was the upstream — such an experiment can sometimes impact how we see things.

You can use the described heuristic to fix some relationships or to create them wisely if you integrate new Bounded Contexts. Of course, there are always more nuances, like, for example, changes in model vs. changes in contracts, but that can be a topic for a different story 😉