Common Microservices Design Patterns

In a microservices design, you need to worry about its inner and outer architecture. The inner architecture defines how you design a microservice itself, and the outer architecture talks about how it communicates with other microservices. Unless you make both the designs simple and easy to evolve, you make the system error prone and move away from key microservices design goals. At its core in any microservices design, time to production, scalability, complexity localization, and resiliency are key elements. Unless you make the design simple, it’s hard to reach these expectations.

Domain-Driven Design

Domain-driven design (DDD) is not a new concept introduced with microservices and has been around for quite some time. Eric Evans, in his book, Domain-Driven Design: Tackling Complexity in the Heart of Software, coined the term Domain-Driven Design. As microservices became a mainstream architectural pattern, people started to realize the applicability of domain-driven design concepts in designing microservices. This design plays a key role in scoping out microservices.

It is mainly about modeling complex business logic, or building an abstraction over complex business logic. The domain is at the heart of a domain-driven design. All software we develop is related to some user activity or interest.

Some domains involve the physical world. In the retail business, you find buyers, sellers, suppliers, partners, and many other entities. Some domains are intangible. For example, in the crypto-currency domain, a Bitcoin wallet application deals with intangible assets. Whatever it is, the domain is related to the business, not the software. Of course, software can be a domain itself when you build software to work in the software domain, for example a configuration management program.

Throughout this book we’ll be using many examples to elaborate on these concepts. Let’s say we have an enterprise retailer that is building an e-commerce application. The retailer has four main departments: inventory and order management, customer management, delivery, and billing and finance. Each department may have multiple sections. The order processing section of the inventory and order management department accepts an order, locks the items in the inventory, and then passes the control to billing and finance to work on the payment. Once the payment is successfully processed, the delivery department makes the order ready for delivery. The customer management department takes the ownership of managing all customer personal data and all the interactions with the customer.

Figure: Divide and Conquer

One key principle behind domain-driven design is divide and conquer. The retail domain is the core business domain in our example. Each department can be treated as a sub-domain. Identifying the core business domain and the related sub-domains is critically important. This helps us build an e-commerce application for our retailer following microservices architectural principles. One of the key challenges many architects face in building a microservices architecture is to come up with the right level of granularity for each service. Domain-driven design helps here. As the name implies, under domain-driven design, domain is the king!

Let’s take a step back and look at Conway’s law. It says any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure. This justifies identifying sub-domains in an enterprise in terms of departments. A given department is formed for a purpose. A department has it own internal communication structure, as well as a communication structure between departments. Even a given department can have multiple sections, where we can identify each such section as a sub-domain.

Let’s see how we can map this domain structure into the microservices architecture. Possibly we can start building our e-commerce application with four microservices: Order Processing, Customer, Delivery, and Billing.

Figure: Communication between microservices

---

Happy Exploring!