Microservices Architecture Pattern

Previously we talked about the notion of building a context map to make sense of the current architecture. Same context map can be built for a brand new greenfield build out as well. Now let's go beyond the context map and talk about Microservices. Everyone I talk to say they are doing micro services but in reality only a handful of architectures are truly microservices. Most of the architectures I have seen are between a monolithic architecture and a microservice architecture.

Origins of microservices can be traced back to 1999 HP labs but it really started to get traction in 2011 where the current term "microservice" was used in a software architect workshop held near Venice to describe a common architectural style. This architectural style was officially coined as "microservices" in 2012. Microservices is a specialisation of an implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems.

In that same period Domain-Driven Design (DDD) an approach to software development was gaining popularity among the architecture communities. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns which simply changed my life as an Architect and CTO. I have had great success with combining domain driven design principles with microservices to build great scalable and durable architectures that can evolve with the business.

Microservices Architecture Pattern

Let's take a look at what a good microservices architecture pattern that is following domain driven design would look like. We need to keep in mind that microservices architecture promotes 2 important concepts.

1. It promotes a 100% shared nothing approach compared to SOA architecture which promotes shared everything.
2. It promotes choreography over orchestration. This topic needs a more in depth study and requires a dedicated article. In my opinion choreography need to be as lite as possible to avoid complications. This can be achieved through the right microservice granularity and the process to achieve the right granularity is DDD.

The microservice architecture pattern has 4 important call outs.

1. API Layer
2. Distributed Communication 
3. Service Components
4. Microservice

API Layer

API Layer is an important concept in the microservices architecture pattern. The API layer in front of the services acts as a service-access facade. This is an abstraction layer to the outside world. This is important as the service consumers don't have to know the actual location of the service endpoints. The other benefit of this abstraction layer is that it allows your teams to manage the granularity of services over time without impacting the end consumers. This API layer sets up the foundation for underlying microservices to evolve without constantly having to inform the service consumers about the changes.

Abstracting service granularity into well formed APIs will require some level of service orchestration at the API layer. This is something that needs to later be refactored out overtime. If not this orchestration layer will grow larger as the architecture ages and new developers add more orchestration to this layer. It is important to strictly manage the API layer and optimise to improve developer experience from a consumer perspective. Building this API layer should be done in an intelligent way to prevent a bad developer experience for the consumers.

Distributed Communication

Microservices architecture pattern is inherently designed to be distributed in nature. With all underlying microservice implementations being shared nothing, and these components within the architecture being fully decoupled from one another, communications between these components, and API layer requires a remote access protocol. Medium for distributed communication for example can be JMS, AMQP, REST, SOAP, RMI protocols via a lite weight infrastructure. The distributed nature of this architecture pattern is how it achieves some of its superior scalability and deployment characteristics. 

Service Components & Microservice

Now comes the most important concepts of the microservice architecture pattern. A service component is best categorised as a collection of modules. The granularity of these modules can vary from a small to large portion of the application. These modules represent either a single purpose function or an entire independent portion of a large business application. Designing the right level of service component granularity is one of the biggest challenges within a microservices architecture. This is where the Domain Driven Design comes into play.

The DDD approach is an excellent methodology to really nail down the right granularity for your service component. I have had great success using the DDD process to arrive at the right microservice granularity. In the previous article we discuss about the context map and how it can be used to map out your current architecture. This is going to be the starting point of the process to identify the right granularity of a microservice. Below is the high level process in DDD to get the granularity right in a microservice.

Context Map

Mapping of relationships and integrations across multiple bounded contexts of a large scale system is referred to as the Context Map. A large scale enterprise system or platforms consists of multiple models, therefore multiple bounded contexts. These bounded context’s integrate and relate together. This mapping of relationships and integrations across a large scale system is referred to as the Context Map of the system in question. 

Bounded Context

Explicitly define the context within which a model applies. Keep the model strictly consistent within these bounds, without being distracted or confused by issues outside the bounded context.

• Most important concept to grasp
• The setting in which a word or statement appears that determines its meaning
• Explicitly define the context within which a model applies
• Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas
• Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside

Domain Model

Representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. This model can then be used to solve problems related to that domain.

• A system of abstractions representing selected aspects of the business. 
• An abstraction of reality
• A simplification with a focus on relevant concepts honing in on the problem space.

Ubiquitous Language

The terms and phrases within a bounded context in diagrams, writing and speech. This “common language” is used to describe the domain model within the bounded context and the organisation.

• A shared language used by developers and stakeholders alike
• Translation plus risk of misunderstanding is too high of a cost to not have one
• Uses the model as the backbone of the language
• Changes to the language, should cause a refactoring to code

Microservice

Physical manifestation of the bounded context as a shared nothing microservice that exists independently within a microservice architecture pattern. This microservice holds the service context and its modules exposed via well defined API endpoints. I like to call these microservices "coarse-grained microservices" which will be the final output of the DDD process.

References

1. Software Architecture Patterns by Mark Richards - https://www.oreilly.com/content/software-architecture-patterns/
2. Microservices vs. service-oriented architecture - https://www.oreilly.com/radar/microservices-vs-service-oriented-architecture/#microservices_architecture_topology
3. Domain Driven Design Content by Martin Fowler - https://martinfowler.com/tags/domain%20driven%20design.html
4. Domain Driven Design by Eric Evans - https://www.domainlanguage.com/

We will discuss more in depth topics around microservice implementation as part of the platform fundamentals 101 newsletter.

Dhanush Hetti