Uber's Domain-Oriented Microservice Architecture
also called DOMA
After growing to roughly 2,200 microservices, Uber grouped them into domains behind gateways with strict dependency layering, to recover the comprehensibility that fine-grained decomposition had cost.
What happened
Uber moved from a monolith to microservices to gain team autonomy and independent deployability. It worked, and then it kept working: by around 2018 the estate was in the region of 2,200 services.
The published account ("Introducing Domain-Oriented Microservice Architecture", 2020) is candid about the cost. Nobody could reason about the whole. A single product change might touch dozens of services owned by many teams. Dependency graphs were effectively unreadable, testing required enormous fixtures, and onboarding an engineer meant learning an incomprehensible map.
The response
Not a return to a monolith. Three structural rules layered on top of the existing services:
1. Domains. Collections of related services treated as one unit — the smallest thing a consumer should have to know about. Consumers depend on a domain, not on the services inside it.
2. Gateways. Each domain exposes a single interface. Internal services are free to change, split and merge without any consumer knowing, which restores the encapsulation that direct service-to-service calls had dissolved.
3. Layer design. Domains sit in layers, and a domain may only depend on layers below it. This is the dependency rule from layered architecture applied at estate scale, and it is what turns a graph into something with a direction. It also means a failure in a lower layer has predictable upward impact, which the previous arbitrary graph did not.
The lesson
Microservices solve an organisational problem and create an architectural one. Independent deployability is genuinely valuable; unbounded fine-grained decomposition produces a system whose complexity has simply moved from inside the code to between the services, where it is harder to see and much harder to refactor.
The general principle DOMA embodies: there must be a unit of abstraction larger than a service. Without one, the number of things a person must hold in mind grows with the estate rather than with the domain — which is cognitive load as an architectural constraint.
Note also what did not happen: they did not consolidate the services. The fix was hierarchy and encapsulation, both of which could be added incrementally, rather than a migration.