Organizations adopted microservice architectures due to the numerous benefits they provide such as flexibility in the form of independent deployments, clear ownership, improvements in system stability & reliability, and better separation of concerns. Microservices architecture helped systems become more flexible and allowed teams to be more autonomous.
In an organization, as number of microservices grew, it increased the complexity and sometimes making even trivial features difficult to build. With a microservice architecture one trades a single monolithic code base for black boxes whose functionality can change at any time and easily cause unexpected behaviour. Understanding dependencies between services can become quite difficult, as calls between services can go many layers deep and require extensive collaboration across teams. A latency spike in the nth dependency can cause a cascade of issues upstream. Visibility into what’s actually happening is impossible without the right tools, making debugging difficult.
Many organizations are attempting to reduce microservice complexity while still maintaining the benefits of a microservice architecture by adopting generalized approach to microservice architectures, “Domain-Oriented Microservice Architecture” (DOMA).
Domain-Oriented Microservice Architecture
The core principles and terminology associated with DOMA are as follows:
- Instead of orienting around single microservices, orient around collections of related microservices called domains.
- We further create collections of domains which we call layers. The layer that the domain belongs to establishes what dependencies the microservices within that domain are allowed to take on. We call this layer design.
- We provide clean interfaces for domains that we treat as a single point of entry into the collection. We call these gateways.
- Finally, we establish that each domain should be agnostic to other domains, which is to say, a domain shouldn’t have logic related to another domain hard coded inside of its code base or data models. Since frequently teams do need to include logic in another team’s domain (for example, custom validation logic or some meta context on a data model), we provide an extension architecture to support well defined extension points within the domain.
In other words, by providing a systematic architecture, domain gateways, and predefined extension points, DOMA intends to transform microservice architectures from something complex to something comprehensible: a structured set of flexible, reusable, and layered components.
Reduced Complexity
Previously teams would have to call numerous downstream services to leverage a domain; they now have to call just one. By reducing the number of touchpoints to onboard a new feature, platforms were able to reduce onboarding time by 25-50%.
Extensibility and Maintainability
Platforms designed using DOMA have proven to be much more extensible and easier to maintain.