[1/2] Introducing Domain-Oriented Microservice Architecture (Category Architecutre)

In 2020 Adam Gluck wrote about it. post Redesigning Uber’s microservice architecture and moving to DOMA And then Adam quit and went to saw his startup, but that's irrelevant:) If you go back to the article, Adam described the stages of the evolution of architecture.

1. Monolithic architecture (roughly 2012-2013)where 2 Big service and a set of problems: availability risks, dangerous depletion, poor separation of concerns, poor execution of changes in business logic. These problems arose with the growth from dozens of engineers to hundreds.
2. In solving these problems, the boys went to microservice architecture System-wide reliability, separation of concerns, clear responsibility and ownership (ownership)speed of development (developer velocity). The guys in the initial stages got everything planned, but as the team grew to thousands of engineers, a distributed monolith appeared.
3. S 2018 I have been working on a new concept called **DOMA (Domain-oriented microservice architecture)**In which the guys decided that microservices are just i/o-bound libraries, and microservice architecture is a large distributed application, then for its architecture you can use standard approaches.

• Domain-driven design The most interesting thing to read about this concept is in Vlad Hononov’s book “Learning DDD”, which I wrote. 4 summary: general overview, DDD and microservices, DDD and event-driven architecture, DDD and data mesh
• Clean architecture The book "Clean Architecture" and its part about the design of modules - my brief sammari of this part. here
• Service-oriented architecture This is the forerunner of microservice architecture:) And the result is principles for the design of large distributed systems in large organizations.

Basic principles DOMA such

1. Instead of focusing on individual microservices, we should focus on their collections, which are organized around domains.
2. In fact, domains are also combined into collections called levels. Levels determine what dependencies microservices can have within a domain. The basic rule is that microservices from the upper layers can only depend on microservices from the lower layers. The authors call this layered design. To me, it resembles a seven-tier OSI model. (||Technology often evolves in circles.||)
3. Domains provide clean interfaces (clean interfaces)This is a single entry point to the collection. These entrance points are called gateways.
4. There can be no dependencies between domains, neither by code nor by data models. To make it possible to incorporate logic from one domain to another (For example, for custom validation or meta context) Authors provide extension points within domains

Domains allow you to think about the logical role of a collection of microservices and can be of different sizes. Domain collections in the form of layers are a way to control the specificity of the layer and its blast radius. In total, five layers were allocated to Uber.

1. Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
2. Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
3. Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
4. Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web).
5. Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

End of review in next post.

#DistributedSystems #Architecture #SystemDesign #Engineering #Software