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, managing complex monolithic applications is much harder than managing a small service, for developers as well as Quality Assurance (QA) teams. A potential method of reducing the complexity of a monolithic application is by using a distributed application development approach, which refers to the decomposition of a monolithic application into several smaller microservices. It is important to consider how microservices can be made to achieve the same business goal as the original monolithic application. Microservices provide a perfect...

Business capability refers to structured modeling, which provides a high-level overview of the business. Business capabilities are the top layer of the business architecture and belong to the business domain. We can split a monolithic application into services based on their business capabilities. These services have broad context boundaries, including user interface, persistent storage, and any external collaborations. Consequently, the teams are cross-functional and include the full range of skills required for the development: user experience, database, and project management.

A business capability refers to how a business architecture model behaves in order to achieve a business goal. A business capability is similar to a business object. Let's define the services of our application based on its business capabilities:

• Customer...

You can also split a monolithic application into a microservice-based application based on its domain. The domain decomposition methods focus on a bounded context, which is a central pattern of Domain-Driven Design (DDD). Domain decomposition methods split a domain into subdomains. You can define services that correspond to the subdomains of the 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

The main challenge of this approach lies in identifying the subdomains...

In any new application development, you are often required to implement particular scenarios or services, such as cross-cutting concerns. You have to spend a significant amount of time implementing common cross-cutting concerns in the development of a new application. Let's have a look at the following cross-cutting concerns:

• Build system and externalized configuration: We have to choose either a Maven or a Gradle-based system to compile, package, version, and resolve external dependencies. This will also deal with further external configurations, such as credentials, and the network locations of external services, including databases or message brokers.
• Implement logging: Logging is also required for all services of a new application development. You have to configure a logging framework, such as Java, Log4j, Logj42...

In this section, we will discuss how to build a microservice-based application using the same online bookshop example as in the previous sections. Our application has the following four modules:

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

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...

SOAP and RESTful microservices have the following differences:

In this chapter, we have discussed the decomposition of a monolithic application into a microservice-based architecture. You can decompose a monolithic application based on either its business capabilities or its domain. Business capabilities are the processes that are required for the business goal. In domain-based decomposition, we can use a bounded context, which is a central pattern for the DDD. In the DDD, we have to identify the domain's subdomains, each of which has a corresponding service in the application architecture.

We have built an online bookshop application with a microservice architecture. We have also discussed the differences between SOAP and RESTful microservices.

In Chapter 3, Microservices Deployment Patterns, we'll gain an understanding of how to deploy microservices and how these services communicate with each other in the architecture...