Domain-Oriented Microservice Architecture
eng.uber.com
Domain-Oriented Microservice Architecture
1–10 of 116 posts
Re: Domain-Oriented Microservice Architecture
#2Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well.
I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take to building services. All the material I've read seems to point in the direction of services being ideally coupled to domain boundaries.
It seems to me that Uber's services proliferated beyond the framing of bounded contexts, and DOMA is their attempt to reign it back in again. I think it's an excellent strategy, and arguably a very good approach for other companies who find themselves in this position.
I don't think DOMA is a good place to stay at. The network should only be tolerated as long as it provides benefits that outweigh the costs. "Monolith" is not synonymous with "poor design". Seeing that these enclaves of services sitting within a domain depend on eachother in the way the OP describes, it really makes me think that they'd find further benefits by expelling the network from each domain.
Re: Domain-Oriented Microservice Architecture
#3Seems to me that big progress will be made when we can decouple system boundaries from network calls.
Re: Domain-Oriented Microservice Architecture
#4Basically clumping microservices
Re: Domain-Oriented Microservice Architecture
#5Depending on what angle you come at this from, you could say that DOMA groups services into clusters ("domains"), as Uber has done here, or that services always should have been domain-driven, and DOMA welcomes the networking layer inside the bounded context as well. I've spent a lot of time trying to understand when a microservices architecture makes sense, what the caveats are, and what philosophy one should take t…
> The network should only be tolerated as long as it provides benefits that outweigh the costs.
I agree. There should be no need to use network calls to enforce interface boundaries if you have a cohesive bounded context.
Or to be snarky about it, welcome to 2004 Uber! Eric Evans sends his regards!
Re: Domain-Oriented Microservice Architecture
#6hi guys.
my hot photos are here...
https://mub.me/xxxxi
my nickname anna1
Re: Domain-Oriented Microservice Architecture
#7Somewhat off topic but maybe someone can enlighten me:
> Uber has grown to around 2,200 critical microservices
Even thinking about the very largest systems I’ve worked on, I can’t think of what could possibly be split into 2000 separate individual services. What are these thousands of microservices and how micro are they?
Re: Domain-Oriented Microservice Architecture
#8Somewhat off topic but maybe someone can enlighten me: > Uber has grown to around 2,200 critical microservices Even thinking about the very largest systems I’ve worked on, I can’t think of what could possibly be split into 2000 separate individual services. What are these thousands of microservices and how micro are they?
I'd be curious how that compares to Amazon's count of services (my guess is 10k+)
Re: Domain-Oriented Microservice Architecture
#9Seems to me that big progress will be made when we can decouple system boundaries from network calls.
I still think the approach of baking the entire enterprise into 1 gigantic binary is the best. Stack traces are so much easier to work with compared to distributed logs and side effects.
We are already at a point where you could hypothetically do this for a reasonably-sized organization. A 64 core CPU can support a huge number of clients. Stuff like .NET Core scales really well if you want to build something complex like this. One big binary that occupies an entire physical host is an extremely compelling development model. Literally everything becomes a direct method invocation. You can also have type enforcement and atomic releases for the entire enterprise. Also makes a monorepo an obvious choice for source code management.
Re: Domain-Oriented Microservice Architecture
#10While I work on much smaller codebases and so don’t have any particular insight into how DOMA will work for such large organizations, the piece that I really liked here is how the separate their different general layers of services.
The key to any service being usable outside of the exact context it was first written in is to ensure no product specific business logic is added to it.
By splitting out infrastructure from general business from product specific services, you can do a much better job of understanding, and therefore controlling where where product specific logic is allowed. This in turn will make your lower level services far less coupled to the exact context they are first used in.
For smaller orgs, this is by far the more useful information, rather than how to deal with 2200 microservices.