Application Decomposition to Microservice

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.

Why Microservices?

• Agility: Microservices enables organizations to independently iterate and ship features, reducing the time required to meet the needs of the market.
• Organizational Flexibility: Microservices enables organizations to create independent teams of different sizes and structures based on the needs of a given feature or function.
• Technologies Diversity: If you want to work with the latest technology. Microservices enables you to incrementally adopt and test new technologies. You also want engineers to be productive from the day they start. With microservices, engineers can start coding on a small microservice, with no need to master a complex code base.

There are many other reasons to choose Microservice architecture pattern as your primary software architecture pattern for your application development.

Application Decomposition to Microservice

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.

Application context boundaries

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 legacy system to microservice

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.

Application decomposition based on business capability

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:

• Account Management is responsible for managing account details of customers
• Order Management is responsible for managing customer’s orders
• Book Inventory Management is responsible for managing the book’s inventories
• Shipping Management is responsible for managing shipped orders

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.

Benefits

This approach has the following benefits:

• The architecture is stable since the business capabilities are relatively stable.
• In the microservice architecture, each development team focuses on delivering business value rather than technical features. These teams are cross-functional and autonomous.
• The microservice approach provides a cohesive system that has loosely coupled services.

Issues

There are the following issues to address:

• How to identify business capabilities!
• Organization structure – different groups within an organization might correspond to business capabilities or business capability groups.
• High-level domain model – business capabilities often correspond to domain objects

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:

• Account Management
• Book Inventory management
• Order management
• Shipping management
• …

Let’s move on to the next section, where we will discuss another approach for decomposing a monolithic application to a microservice-based application.

Application decomposition on the basis of domain

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:

• Customer Account Management
• Book Inventory Management
• Order Management
• Shipping Management

Benefits

This pattern has the following benefits:

• Stable architecture since the subdomains are relatively stable.
• Development teams are cross-functional, autonomous, and organized around delivering business value rather than technical features.
• Services are cohesive and loosely coupled.

Issues

There are the following issues to address:

• How to identify the subdomains!
• Organization structure – different groups within an organization might correspond to subdomains
• High-level domain model – subdomains often have a key domain object

Building Microservices design for your application

I will create a microservice for each of these modules. The following microservices correspond to the application modules:

• Customer Account Management → Account Service
• Order Management → Order Service
• Book Inventory Management → Book Service
• Shipping Management → Shipping Service

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:

• Config Server
• Eureka Server
• Account Service
• Book Service
• Order Service
• Shipping Service
• Zuul Proxy API Gateway

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.

Conclusion

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.