Nowadays, many software applications and systems are so complex (huge number of requirements) that without the proper designing very fast are built a ‘big ball of mud’ or ‘distributed monolith’ – systems that is very hard to maintain and extend. Designing is really important. Let’s see why.

How to properly design a system? First, you need to discover the domains. Why? Let’s look at example.

In a larger organization, the interactions between employees could look like this:

Now we will draw the areas with the densest interactions:

It turns out that these marked areas are interactions within departments. Let’s name these departments:

This shouldn’t surprise anyone. Within the departments, most business processes or sub-processes take place, hence so much activity/interactions. Of course, there is communication between departments as well, but not much.

Ok, but how do these scribbles relate to IT systems or microservices? These four departments determine the subdomains, and for each subdomain we build microservice, so we have:

It is beautiful. The amount of communication between modules/microservices is small, and the implementation of functionalities/business requirements is constrained to one module! This is one of the most important aspects of building high-quality solutions – low coupling, and high cohesion. This makes microservices maintainable and extensible, programmers know what’s going on, etc. lots of advantages.

When we want to build software, at the beginning we create requirements mainly for … interactions/activities in the organization, and then we implement the requirements as interactions in the software:

In the software, we reflect the processes and interactions in the organization. In every organization, we want departments and teams to be autonomous, independent of others, and we want the same for the software. We want most interactions and processes to be inside departments and teams because they don’t have to collaborate with others. We want the same for the software module/microservice

Discovery of domains is one of the first steps in system modeling and design to properly define module/service boundaries, which later translates into more autonomy and less dependency between modules/services. The departments used in examples is one of the criteria/clue/heuristic of (sub)domains discovery.

How to discover (sub)domains? Check this post: How to discover (sub)domains