In this article, will discuss Microservices in details, usage of application & services, application decomposition to Microservice architecture on the basis of Business capability and domain and subdomain.
In the previous article, we have discussed the Software architecture patterns and designs like Monolithic, Service Oriented Architecture (SOA), and Microservice architecture. We have also discussed, the pros and cons of each software architecture patterns, but you can decide suitable software architecture patterns based on your business requirements and business capability.
According to current requirements, most software companies start application development based on the Microservice architecture due to scalability and technologies diversity.
There are many other reasons to choose Microservice architecture pattern as your primary software architecture pattern for your application development.
One of the biggest challenges in using a microservice architecture is deciding how to break an existing, complex monolithic system into several services. A microservice architecture structures a complex system into more manageable, separate services, each of which focuses on a specific part of your business goal.
As we know that managing complex Monolithic application is very harder than a small service not even for developers also for QA teams. So, the Distributed Application Development could be a potential solution to reduce this complexity of the Monolithic application. So, the distributed application approach is not a thing but its all about the decomposition a Monolithic application into several smaller microservices.
If you distribute a Monolithic application into several microservices, then how to achieve the business goal as in Monolithic. The orchestration and choreography of the Microservices are one solution to achieve this business goal. This approach provides perfect modularity because of independent design, development, deployment, and maintenance of several modules.
Let’s look at the following monolithic application diagram:
As you can see, the application is packaged as a single WAR or EAR file. All the services related to this application run in the single-server process. It uses the central database and is based on a centralized services approach.
Decomposition of the Monolithic application is one of the challeges to decide modules. It depends on your business application and how many modules of your business application you want to create. So, the module is nothing but it is a way of defining context boundary. So, first, you have to identify a hidden context in the current Monolithic application at the time of migrating existing Monolithic application to Microservices.
Let’s move on to looking at how to decompose this application into microservices.
A module is just a way of defining a context boundary. If you want to migrate your existing monolithic application to a microservice-based application, you first have to identify a hidden context within your current application. This means we have to define the context and draw explicit context boundaries. This helps us design a robust microservice-based application.
For example, a typical online book shopping portal can have an order and shipping module using the same entity product. The following diagram shows the context boundaries of this application:
As you can see in the preceding diagram, the distributed application is based on different bounded contexts. The preceding design is a modular application design, where every module runs an independent process as a service. This is a decentralized approach to application design.
Once if you defined the context boundaries, then you can easily decompose your existing monolithic application into microservice based application. Where each bounded context has one Microservice. In our example in the above diagram, we have divided our monolithic application into four bounded contexts, that means there are four microservices such as Order Service, Book Inventory Service, Shipping Service etc.
Now we have separate product entity in order Microservice and shipping Microservice with their respective repositories. A similar concept can be extended by defining explicit context boundaries for stock and inventory module, by creating an independent Microservice for each.
Decomposing a monolithic application into Microservice is not always simple because of the complexity of business processes. We can start Microservice adoption with an initial focus on only new features that can be planned as Microservice. ACL (Anti-Corruption Layer) pattern can be used here for doing this data transformation with the legacy system.
Let’s see the decomposition approach of a monolithic application. You can decompose a Monolithic application based on either business capability or the basis on the domain.
The business capability means a structured modelling that provides a high-level overview of the business. Business Capabilities are the top layer of the business architecture. The Business Capabilities belong to a Business Domain. The microservices approach can use the business capabilities of a business model to modularize into services.
We can split a Monolithic application into services based on business capability. The services based on the business capability has broad context boundaries including user-interface, persistent storage, and any external collaborations. Consequently, the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.
Let’s define the services of your application based on business capabilities. The business capability is the behaviour of a business architecture modelling to do in order to achieve the business goal. So, we can also say a business object is like a business capability. Let’s see the following example:
It is important to understand the core components of the business, such as the user interface, service, data, logging, or messaging. Business capabilities mostly depend on the business and are primarily organized in multiple layers.
A microservice architecture would have services that correspond to each of these capabilities, as follows:
The preceding diagram shows the decomposition of a monolithic application based on its business capabilities. We have identified four business capabilities of the online bookshop application and created a service to correspond to each.
The challenging part of this decomposition is how to identify the business capabilities. Nobody identifies business capabilities perfectly, but a useful place to start is by analyzing the organization’s purpose, structure, and business processes.
This approach has the following benefits:
There are the following issues to address:
You must understand the core components of the business such as user-interface, service, data, logging, messaging etc. Business capabilities are most of depends on the business and these are mostly organized into multiple layers for a business. Let’s see the following example with the business capabilities:
Let’s move on to the next section, where we will discuss another approach for decomposing a monolithic application to a microservice-based application.
You can also split the Monolithic application into a Microservices-based application by decomposing on the basis of the domain. The domain decomposition methods focus on a bounded context. The bounded context is a central pattern of the Domain-Driven Design (DDD). Domain decomposition methods split a domain into subdomains. You can define services corresponding to the subdomains of the Domain-Driven Design (DDD). As shown in the following diagram:
The preceding diagram shows a decomposition based on subdomains. Each subdomain has a corresponding service. Subdomains can be classified according to business processes. For example, as you can see in the preceding diagram, we have decomposed the online bookshop application into the following subdomains:
This pattern has the following benefits:
There are the following issues to address:
I will create a microservice for each of these modules. The following microservices correspond to the application modules:
The following diagram shows the architecture of this online bookshop application:
As you can see in the preceding diagram, we have four core microservices in this application. This architecture also has two more services: an API Gateway and the Shopfront UI web application, which is the user interface that can be seen on the browser. To start building our microservice project, we have to create the following individual services:
We will see the code of its implementation in the coming article very soon. Even, you can see another article of building microservice using the Spring Boot.
In this article, we have discussed software application architectures such as a Monolithic, Microservices, and Service Oriented Architecture (SOA). A Monolithic architecture means building an application including all its modules as a single artifact. It is better for simple, and lightweight applications.
But a Monolithic architecture has various drawbacks such as after some time it has a massive code base and very difficult to manage. After making a small change in the code base we have to build a new version of the complete application code base and deploy this new version to the server. To resolve the problems of the Monolithic architecture we can use another microservice architecture.
A microservices-based architecture resolves many of monolithic architecture’s problems. This architecture uses an approach to decompose a Monolithic application into several different and independent processes. These processes are known as microservices. The Microservices architecture pattern is the better choice for complex, evolving applications. This architecture handles a complex system in a better way as compared with a monolithic architecture.
Strategy Design Patterns We can easily create a strategy design pattern using lambda. To implement…
Decorator Pattern A decorator pattern allows a user to add new functionality to an existing…
Delegating pattern In software engineering, the delegation pattern is an object-oriented design pattern that allows…
Technology has emerged a lot in the last decade, and now we have artificial intelligence;…
Managing a database is becoming increasingly complex now due to the vast amount of data…
Overview In this article, we will explore Spring Scheduler how we could use it by…