Designing a robust microservices architecture starts by identifying the business domain, defining the capability around that domain, and then defining microservices around it. Breaking down a business domain can be achieved with the concept of Domain-Driven Design (DDD), an approach to software development for complex needs which connects the implementation to an evolving model.
The term DDD was introduced somewhere in 2004 with buzz keywords such as modeling, bounded context, entity, repository, and ubiquitous language. As DDD fits perfectly with the idea of microservices, this concept is again getting hype because of the popularity of microservice architecture. The philosophy of DDD is to try to understand the domain of a problem that we are trying to solve and model it around this domain. It suggests modeling on the basis of real business use cases. This modeling includes defining a set of concepts for domain, capability of domain, and bounded context around it. There are some basic concepts in DDD, which are as follows:
- Ubiquitous language: This means all the stakeholders (business, operation, developer) should share the common language (terminology) that should not be too technical, rather it should be more focused on the business side model. This language will be related to the bound context of domain.
- Bounded context: The main idea is to define the scope of a model, to define the clean boundaries of its context, and then do the most possible to keep the model unified. The defined model should be kept consistent and restricted within defined boundaries. Each bounded context should be independent to other context. It defines the separation of duties between the domains. Any particular business can have multiple domains in it such as shipping, inventory, sales, marketing, and so on. Each domain has its own capabilities. Each entity or component of a business remains in its own bounded context. DDD concept helps us identify these domains and their segregation point. This whole concept of DDD matches with microservice principles. Think around a model, encapsulate the model around bounded context, and these contexts define the boundaries.
As microservices should be isolated, it becomes more necessary for a microservice to have a clear responsibility or boundary. When adopting DDD, the bigger problem domain can be decomposed into smaller ones with bounded context, which will lead to a better understanding of defining microservices around them. If we don't do this clear boundary separation, we will have a leakage of responsibility in between microservices, and then we will have a big ball of mud without having any clear boundary. DDD helps in understanding and defining boundary context. A very good read on DDD is Implementing Domain-Driven Design by Vaughn Vernon ,which gives you a deep understanding of Domain-Driven Design.
Microservices empower the organization with speed. They allow the organization to respond to the market in a quicker fashion. They improve the productivity, delivery, and, of course, the speed in delivering projects. The challenge in this format is to align your team inside the organization around this architecture efficiently. Microservices don't suit or fit every organization. Implementing microservice architecture can tweak the parameters inside the organization also.
Business capability can be defined as an independent operation service for a particular purpose in business. Business capability in the organization can be defined at each level/domain. The upper management level can have different capability definitions, operations can have different ones, sales can have different ones, technology can have different ones, and so on. So, identify the fine grain business capability and arrange the microservice around them.
Business capability and microservice seem to be the same by definition, but they is not. Running a promotional campaign is a business capability for the marketing department. After identifying this capability, start arranging the microservice component around it, such as email sender service, promotion link generator service, data collector service, and so on. It's a two-step process:
- Identifying the correct business capability.
- Defining the microservice component around it.
Both steps have to be done and fine grained as much as possible. This will help design the architecture efficiently.
Another important factor is communication. Communication is a live wire in any business and in any form. There can be communication between teams, between organization and end user to get constant feedback, communication between different levels of management (upper, middle, lower ), and even communication between components of the software system of that organization. There is a law that relates communication between software components and how communication happens within the organization. The law is Conway's law.
As per Conway's law, Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
This may seem hard to believe or may not be a valid statement to some people initially. Regardless of that, some of the well-known institutions such as MIT and Harvard take it seriously. They have done studies on this law, and compared some code based with the organization structure under which these codes develop. What they found is that this law works! Yes, indeed, 90 percent code bases in different segments, as they picked for their study, aligned perfectly to this statement. To understand it more let's see how it is proven in a monolithic application case. If you have one big developer team that is co-located in the same building, you will end up in a monolithic application. On the other hand, if you have small teams, members of one team should be co-located, but teams may not necessarily be co-located. Then, you will end up having distributed or multi-module application architecture, as in the open source projects. Open source projects have a kind of distributed and modular architecture. They have a number of small teams (even with a single member in a team) rather than one big co-located team. Then, these teams are not co-located. This law doesn't tell us anything about microservices, but it tells us how the team structure or organization structure can affect application design.
As per the law, the application architecture will be a copy of your organizational structure, but there is a high chance that your organizational structure can also have an impact on your application architecture. Team locations and team communication impact the application architecture, which can result in an aligned organization structure.
If an organization has five teams with four team members in each team, we encounter a situation where it is not easy to break down a service to be handled by one team. The joining of two teams could be a solution here. This is basically changing the organizational structure around application architecture.
However, each company has its paradigm, business capabilities and objectives, dynamics, team structure, and communication methods. Implementing microservice architecture can change the organizational dynamics and structure. Any organization should study its own current structure and communication methods so that they can land in the best of their microservice architecture.