Bird's-eye view of a Distributed System - Context Map

In one of my previous posts on Anatomy of Distributed System à la Lokad we were zooming into the design of a system that could be built as a part of SaaS company. Such system was built with and around CQRS/ES concepts.

This approach looks like a nice by-the-book design: bounded contexts that are based on a uniform design and connected together to deliver some functionality. This is the kind of drawing that could be produced by an ivory tower architect or a consultant that is "too expensive to ever touch the codebase".

However as we know, nothing exists in isolation from the real world. Every entity (either biological or digital) is always connected to much larger environment (and is affected by it). In software projects, for instance, you would have other departments to cooperate with, customers to serve and partners to integrate with. You might also have Microsoft and Apple OS to curse about. Even political rivalry between departments A and B in an organization could matter (especially if they share a database).

So there is an immensely complex and diverse ecosystem that surrounds every single software project. There are different technologies, languages, concepts, mentalities and resource constraints. These things do not necessarily belong to the project directly, but could have an extremely strong impact on risks and costs, potentially leading to the difference between success and failure. Good software developer will always consider the most important of these strategic factors, while making tactical decisions.

One of the ways to take some of these factors into consideration is by changing perspective of your system and by looking from bird's-eye view at it and other systems that it is linked to. Let's zoom out of our CQRS/ES-based set of systems in a department (which was discussed in Anatomy post) and look at a bigger picture. We'll include other departments, some of the customers and partners.

This view will be based on "Context Map" approach of DDD but slightly expanded to cover ecosystem within and around the company. I will keep CQRS/ES-based bounded contexts marked with orange border, while "external" ones will have borders of other colors (just like countries on a map).

Ok, now that's a subtle change. We get a lot more variety in colors and shades, which represent differences:

outside elements have technologies and context specifics that differ greatly from ours;
our own elements turn out to have different shades of CQRS/ES implementations as well.

In other words, each bounded context is different. These differences can be caused by a huge amount of internal and external factors. For example, consider these two contexts, which happen to be owned by different organizations:

Obviously, these differences would make different approaches more or less successful than the others. And it actually is perfectly OK to have different approaches and technologies living in the same organization or a project, if this is justified by the environment. Unless, of course you are a developer from a Soviet Russia that has to employ absolutely identical set of tools everywhere (i.e. SQL everywhere, NHibernate everywhere, NServiceBus everywhere etc).

A few vivid examples of ignoring the strategic context, while charging into the battle were clearly demonstrated by Napoleon and Hitler. They came over to visit Russia and stayed over for the winter with such extended and fragile supply lines.

So, please, don't repeat mistakes already covered by history books (these are the most shameful ones) and:

Take into consideration real world that surrounds this project, trends and risks that surround in future.
Split your environment into set of bounded contexts, that could be distinguished by similar language, match with organizational boundaries or technology manifestations. Map the terrain to make it more understandable.
Before considering to apply CQRS/ES (or any other tech) to a given bounded context - consider and compare it with other approaches, their risks and costs.
Delay non-essential decisions as much as possible.
Push for approaches that allow you to capture feedback from real life as fast as possible (lower development friction, faster iterations, simple architectures).
Keep it simple and separated (KISS).

Let me reiterate.

Domain-Driven Design with its approach of bounded contexts that can be joined into a strategic context map - is one of the ways to visualize and represent environment surrounding and affecting a project. This approach can help to take into account all important factors and figure out the tactical details of most implementation, architecture and technology. Sometimes CQRS/ES approach would be the best fit, however more frequently you would have a different set of conditions that require a different solution to the challenge ahead.

Pick your weapons wisely, for they might affect the outcome of the battle and war.

Published: April 07, 2012.

🤗 Check out my newsletter! It is about building products with ChatGPT and LLMs: latest news, technical insights and my journey. Check out it out