First, we will find out what is Monolithic Architecture. Therefore, I will show you how to modify its domain to be ready for Microservice Architecture. In the end, I will briefly tell you the basics of Microservice Architecture and judge its pros and cons.

Monolithic Architecture

Monolithic Architecture is every non-vertically divided architecture. Vertical division in software design means splitting the application into more deployable units. This does not mean that monolith can’t be horizontally divided into layers.

The adjective monolithic refers that the architecture of software consisting of one backend unit. I am saying backend because I believe that monolith can have more than one UI like web and mobile and still stay monolithic.

Communication between components is happening mostly by the method of invocation. If your frontend and backend are physically divided into, for example, API and web client, then it is still a monolith.

Until you divide the backend into more deployment units, you are still using Monolithic Architecture in my eyes.

Single Domain Model

“A domain is the targeted subject area of a computer program. Formally it represents the target subject of a specific programming project.” — Wikipedia

In my words, the domain is the thing why software exists and is about. I wrote more about the domain-centric architectures here.

This is a visualization of parts ripped from the online shop’s domain.

Sales and Catalog subdomains contain a single Product entity. This leads to more concerns in one place, which is always not good. It is a violation of the Separation of Concerns principle.

Forcing one entity for more concerns does not feel right. The entity contains unused properties in both contexts. Sales don’t need to know the product’s category, and the Catalog doesn’t have any usage for information on how the product was delivered to the customer.

To avoid this problem, we need to find the Sales and Catalog context's boundaries to split them apart. This leads us to a Bounded Context.

Bounded Context

Bounded Context is the boundary or perimeter of a context. — Idapwiki.com

To specify the Bounded Context, we need to recognize a contextual scope where the model is still valid.

We can validate the model by asking a simple question within each entity of the domain. For which context is this entity valid?

When an entity is valid for more than one context, it is divided into more than one. Each with properties corresponding with context. After this process, your application is ready for Microservice Architecture.

This is a visualization of part ripped from the online shop’s domain with a divided Product entity.

Microservice Architecture

Microservice Architecture is also known as Microservices. It is the subdivided monolith. Microservices divide the large systems into smaller pieces.

Bounded Context helps us to find the optimal size for one microservice. Microservice should have a small enough model to minimalize communication with the external world and large enough for existential reasons.

Microservice Architecture provides the power of independence. The architecture supports separated development teams, different operating systems, different programming languages, and different business layer architectures like CQRS.

Each microservice has its clearly-defined interface, mostly realized by JSON over HTTP via restful API. The recommended solution for communication between microservices is through a messaging platform like RabbitMQ or Azure Service Bus.

Without a proper message passing tool, the Microservice must know other microservices' locations, and locations can be easily changed.

Summary

The cost curve of development in Microservice Architecture is flattered at large applications. The small applications don’t benefit from microservices and should stay monolithic.

With microservices comes distributed system costs like load balancing and network latency. Such concerns can be nicely handled with orchestrators such as Kubernetes or Azure Service Fabric.

As a next step, I would recommend the Pluralsight course from Mark Heath — Microservices Fundamentals.

Sources

• Martin Fowler’s blog post about microservices.
• Martin Fowler’s blog post about Bounded Context.
• Pluralsight course Clean architecture patterns, practices, and principles.