I have three takeaways from @uber's Domain-Oriented Microservices Architecture. https://eng.uber.com/microservice-architecture/

First, in a very real sense, they are reinventing/rediscovering the very same principle that guided @ericevans0's Domain-Driven Design https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

Second, it is interesting to see the evolution of Uber's development culture.

They note "They note "It’s not an exaggeration to say that Uber would not have been able to accomplish the scale and quality of execution that we maintain today without a microservice architecture."

However "we began to notice a set of issues associated with greatly increased system complexity. 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 behavior."

I would frame this as the precipitating cause that led them to DOMA: they had grown the company into a Big Ball of Microservices, and at some point they crossed a threshold where it just didn't scale.

Third: this is (again) a problem of architecture. You can go so far at having services bubble up from the primordial soup of Wonderful Goodness, but in the end, a mindful, intentional architecture that attends to systemic issues matters. Bigly so.

So, the lessons here are:

1. Good on 'ya, @Uber

2. Architecture matters

3. Always has, always will