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.
High-level architecture of a business that builds digital products
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.
A business domain is usually a large area of the business composed of multiple subdomains.