Ok, I can finally formulate what I meant.

Looking at the dictionary: "Domain - a specified sphere of activity or knowledge." Uber domain is ride sharing. Indeed, it has multiple subdomains, which deal with finances for drivers, finances for passengers, reviews, all that.

I can't imagine a discussion "how big the domain should be". Who is there to decide how big the activity is, or the business line is? Uber, counting "domains" in number of services is just confusing themselves, and the whole world.

Go to an accountant in Uber and ask "how big is your domain?" Won't be surprised to hear answers about importance of their job and the amount of work they do, and not hear anything about services (who damn cares about services anyway)?

The domain is what people _do_. Microservices, or whatever, some core that runs, is just _helping_ (hopefully) people to do their job. The domain is what the real world represents. It is the source of real-world problems, which software aims to solve. "Ride hailing" is a problem and "Uber" with all their microservices supposes to be a solution.

There's no such thing as a "domain service", not in a sense of what Uber means when they use this term. I used such a terminology a long time ago, when I messed up with terms, creating lots of confusion for myself, and my colleagues. Uber has re-invented bounded contexts, that's all. We can argue if the term "bounded context" is better, and I am ready to debate there, with a decent list of arguments, why is it a context, why is it bounded, and why it has near to nothing to do with a particular "domain".

Uber's "discovery" is a typical "millennial invention", coming from people who ignore all the existing knowledge and believe they invented something new, despite those things being described in details decades ago. I wish that Uber engineers pay some attention to all that knowledge that exists in the industry, and pretend to be novel in the areas that are well-mapped, detailed, and studied by prior generations.

Alexey is the Event Sourcing and Domain-Driven Design enthusiast and promoter. He works as a Developer Advocate at Event Store and Chief Architect at ABAX.

Alexey is the Event Sourcing and Domain-Driven Design enthusiast and promoter. He works as a Developer Advocate at Event Store and Chief Architect at ABAX.