Domain‑Oriented Microservice Architecture (DOMA) at Uber: Design, Benefits, and Practical Guidance
This article explains Uber’s Domain‑Oriented Microservice Architecture (DOMA), describing why the company adopted it, how domains, layer design, gateways and extensions are organized, the operational benefits achieved, and practical advice for companies of different sizes considering a similar evolution.
Introduction – Uber has grown to over 2,200 critical microservices and faced increasing system complexity; to retain microservice advantages while reducing complexity, it introduced a Domain‑Oriented Microservice Architecture (DOMA).
What is a Microservice? – Microservices extend service‑oriented architecture, exposing small, well‑defined functionalities via network calls, offering independent deployment, clear ownership, and improved reliability, but at the cost of added operational complexity.
Motivation – Uber experienced availability and deployment risks, poor separation of concerns, and high coordination overhead as teams and services scaled, prompting a shift to a more flexible architecture.
DOMA Overview – DOMA borrows concepts from domain‑driven design, clean architecture, and service‑oriented design, organizing related microservices into domains , grouping domains into hierarchical layers , exposing each domain through a single gateway , and supporting extensions (logical and data) to add functionality without altering core services.
Key Concepts
Domain – a collection of related microservices.
Layer – defines allowed dependencies; higher layers depend on lower ones, reducing impact radius.
Gateway – a single entry point to a domain, analogous to an API gateway.
Extension – mechanisms (logical or data) to augment domain services without changing their implementation.
Benefits – Reduced system complexity, faster development cycles, clearer ownership, improved reliability, and easier migration; Uber reports 25‑50% reduction in integration time and a 70‑domain decomposition of its 2,200 services.
Advice for Different Company Sizes
Start‑ups – weigh operational benefits against added complexity; consider postponing microservice adoption until scale justifies it.
Mid‑size firms – begin structuring services into layers and domains to manage growing dependencies.
Large enterprises – fully leverage DOMA with gateways and layered domains to handle hundreds of services and support platform migrations.
Final Thoughts – DOMA treats a microservice system as a large distributed program, applying proven software‑engineering principles to evolve it gradually; Uber continues to refine DOMA and invites feedback from the community.
IT Architects Alliance
Discussion and exchange on system, internet, large‑scale distributed, high‑availability, and high‑performance architectures, as well as big data, machine learning, AI, and architecture adjustments with internet technologies. Includes real‑world large‑scale architecture case studies. Open to architects who have ideas and enjoy sharing.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.