Ideal enterprise systems are tightly integrated and provide all business capabilities as a single unit that is optimized for a particular technology stack and hardware. Such monolithic systems often grow so complex over time that it becomes challenging to comprehend them as a single unit by a single team. Domain-driven design advocates disintegrating such systems into smaller modular components and assigning them to teams that focus on a single business capability in a bounded context (https://en.wikipedia.org/wiki/Domain-driven_design#Bounded_context). Once disintegrated, all such components are made a part of an automated continuous integration (CI) process to avoid any fragmentation. Since these components are built in isolation and often have their own data models and schema, there should be a well-defined contract to interact with the components...

Once the bounded contexts are identified for microservices and the organization structure is aligned, each microservice must be considered as a product that is tested, deployed, and scaled in isolation by the same team that developed it. A well-designed microservice must never expose its internal data model to the outside world directly. Instead, it must maintain a service contract that maps to its internal model such that it can evolve over time without affecting the dependent microservices.

Component-based software engineering (https://en.wikipedia.org/wiki/Component-based_software_engineering) defines a component as a reusable module that is based on the principles of SoC and encapsulates a set of related functions and data. In the context of microservices architecture, it is recommended to implement each service as a component that is independently swappable...

In monolithic applications, messaging between components is mostly achieved using function calls, whereas for microservices, it is achieved using lightweight messaging systems, often HTTP(S). Using a lightweight messaging system is one of the most promising features of microservices and makes it easier to adopt and scale, as compared to service-oriented architecture (SOA) that uses a complex messaging system with multiple protocols. Microservices are more about keeping the endpoints smart and the communication channels as simple as possible.

In a microservices architecture, often multiple microservices need to interact with each other to achieve a particular task. These interactions can be either direct, via request-response-based (https://en.wikipedia.org/wiki/Request-response) communication, or through a lightweight message-oriented middleware (MOM...

All the APIs exposed by a microservice are accessible via the IP address and port of the host machine on which the microservice is deployed. Since microservices are deployed in a virtual machine or a container that has a dynamic IP, it is quite possible that the IPs and ports that are allocated to the microservice APIs may change over time. Therefore, IP addresses and ports of services should never be hardcoded by the depending microservice. Instead, there should be a common database of all the services that are active for the current application. Such a database of services is called the service registry in microservices architecture and is always kept up to date with the location of the microservices. It keeps the details of all the active microservices including their current IP address and port. Microservices then query this service...

In a microservices-based architecture, the data model and schema must not be shared among bounded contexts. Each microservice must implement its own data model backed by a database that is accessible only through the service endpoints. Microservices may also publish events that can be considered as a log of the changes the service applies to its isolated database. Keeping application data up to date across microservices may also add to the network overhead and data duplication.

Although microservices have their own isolated persistence, an application implemented using microservices may need to share data among a set of services to perform tasks. In a monolithic environment, since there is...

The core philosophy of a microservice environment must be based on the You build it, you run it (https://queue.acm.org/detail.cfm?id=1142065) model; that is, the team working on the microservice must own it end to end, right from development to deployment. The infrastructure required for the team to integrate, test, and deploy any changes must be completely automated. This makes it possible to build a continuous integration and continuous delivery (CD) pipeline, which is the backbone of microservices-based architectures.

The term CI/CD combines the practices of CI and CD together as a seamless process. In a typical microservices-based setup, the team continuously works on...

In this chapter, we learned about domain-driven design and the importance of identifying the right bounded context for microservices. We learned about the hexagonal architecture for microservices and various messaging patterns. We also discussed data management patterns for microservices and how to set up service registries to discover microservices. We concluded with the importance of automating the entire microservice deployment cycle including testing, deployment, and scaling. In the next chapter, we will introduce a real-life use case for microservices and learn how to design an application using the concepts learned in this chapter.