Domain Services: The Next Evolution of Microservices

The microservices era has been good for software architecture. I remember when the idea of multiple databases was punishable by death. But, the over-focus on micro has detracted from the true benefits of microservices which are about improving the quality and speed of development.

Over the past couple of years, I’ve seen organizations referring to microservices as Domain Services. I’ve seen such benefits from this small reframing that I now recommend not using the word microservice and using Domain Service instead.

There have been many criticisms of microservices and many horror stories. But I don’t wish to bad-mouth microservices in order to hype up a new buzzword. I’m grateful for what the microservices movement has achieved and the ideas should continue to be applied.

Anything that can be used can be abused. All good ideas and concepts can be applied in the wrong way. Our job is to build on what works and improve what doesn’t. I’ve seen that framing microservices as domain services retains the benefits of a loose-coupling and removes the obsession with micro.

Microservices also has a lot of baggage which often detracts from meaningful discussion. This is largely due to misapplication and people blaming microservices rather than anything about the concept itself.

What is a Domain Service or Domain API?

A domain service builds on the basic definition of a microservice: it’s a loosely-coupled, independently deployable element of software architecture which is owned by a single team.

Importantly, the emphasis of a domain service is that it represents an area of expertise in which the business develops capabilities in order to deliver products and value propositions to customers.

Domains are part of the logical architecture of a business. An organization builds products that deliver value propositions to customer segments. Products are powered by capabilities that logically exist within business domains.

A business domain is usually a large area of the business in which multiple teams operate. A business domain can be broken down into multiple subdomains. The recommended boundary for a Domain Service is a subdomain because it should not be too large for a single team.

For a concrete example, here is Uber’s definition and some real examples from their business:

Uber domains represent a collection of one or more microservices tied to a logical grouping of functionality. A common question in designing a domain is “how big should a domain be?” We give no guidance here. Some domains can include tens of services, some domains only a single service. The important task is to think carefully about the logical role of each collection. For instance, our map search services constitute a domain, fare services are a domain, matching platform (matching riders and drivers) are a domain. These also don’t always follow company org structure. The Uber Maps org itself is split into three domains, with 80 microservices behind 3 different gateways.

Uber don’t use the term subdomain, and they still prefer to use microservice. Effectively each of their services within a domain represents a part of that domain which I call a subdomain, but you may decide to call it something different.

New Framing, New Problems

Microservices have proven beyond doubt that naming matters. I think we’ve all been involved in many debates about “how big should a microservice be?”, and people pulling up materials telling us that microservices should be 100 lines of code or less. Even in 2021 it’s still a frequent question in my life as a consultant and trainer.

So changing the name will have a significant impact. There’s a risk it may lose some of the current advantages and could introduce new problems. The new problem I’ve seen is now people are asking “what is a domain?”, “how do we find domain boundaries?”, “how do we name domain APIs?”. However, this is a good thing. These are the kind of questions we want people to be asking because they relate to understanding the business and aligning the design of architecture to the business.

Other drawbacks will surely emerge. Every idea can be misused and misapplied, especially good ones. I’m in no way suggesting this is the end-game of architecture, but I have seen enough evidence that it’s a good step forward.

Changing the Narrative Improves Stakeholder Engagement

When using the terminology Domain Service or Domain API I’ve observed a greater level of interest from product owners/managers, business analysts, and other colleagues in an organisation who are more business-focused and less technical.

My feeling is that microservices has been seen as a purely technical concept by non-engineers and non-architects. I don’t typically see those people using the term microservices or engaging in conversations about microservices.

When talking about domain services/APIs, I’ve seen those people using the terms more comfortably and having relatively detailed conversations about defining the boundaries of domain services, how business rules live in domain services and not BFFs, and a real desire to help name the domain services, API endpoints, and concepts they represent.

Not Tied to Any Methodologies or Frameworks

Rebranding attempts are often used to promote new gimmicks or for new thought leaders to establish themselves. This is not attempt to do that. In fact, reframing microservices as domain services is not tied to any ideas or frameworks. It’s more of an attempt to improve collaboration and design culture.

Last year Uber published Domain-Oriented Microservices at Uber, showing us their evolution of microservices to be more domain focused. But you don’t need to follow their approach. Domain-Driven Design has been around for almost 20 years but you don’t need to read, learn, or apply anything about Domain-Driven Design to take a more domain-oriented approach to your software architecture.

No Need to Rewrite Your System

A good microservices architecture (MSA) is already a good domain-oriented architecture (DOA). There is no need to redesign and rewrite your system to be compliant with the latest architecture buzz word.

If you do look at your microservices architecture and feel that it’s not very domain-oriented, that’s a good reason to consider redesign because you are improving the design of your architecture rather than trying to be buzzword-compliant.

Conclusion

It wasn’t me who started the trend of calling microservices domain services or domain APIs. I’ve seen it happening organically at a few large clients over the past couple of years. However I feel that the more business-focused framing is leading to better conversations and better designed architecture, and from now on I’ll be using the terms domain service and domain API. Hopefully the trend of positive results will continue.