DOMA — From concept to application

DOMA — From concept to application

Hello everybody!

These days I was invited to participate in a technical meeting to talk a little about DOMA (Domain-Oriented Microservices Architecture). The idea was to talk a little about the concepts of this orientation in essence. This motivated the writing of this article.

In this article, my idea is to present DOMA in its essence and leave my vision of the benefits and risks in its application. So let’s go!

Uber and DOMA

The DOMA concept was publicly launched in July 2020 by Uber on its blog. According to the article, by mid-2018, Uber had grown to more than 2200 critical microservices. At that time, there was a significant increase in the system’s complexity. Understanding dependencies between microservices took a lot of work as they could go many layers deep. From that pain, DOMA came up with a proposal to reduce the complexity of maintaining the microservices architectural style without losing its benefits.

Despite being “recent”, DOMA is firmly based on already established concepts and guidelines, such as domain-driven design (DDD), clean architecture, and service-oriented architecture. The innovation is in applying these concepts to large, distributed systems.

Concepts and Implementation

DOMA brings with it some main concepts that must be taken into account during its application. They are: domains, layer design, gateways, and extension architecture.

Domains

Domains are collections of one or more microservices linked to a logical grouping of functionality. In other words, they are microservices that together provide functionalities for your platform or ecosystem. There is no ideal domain size. The focus is on defining the logical role of each collection.

Layer Design

We can define “layer design” as a way to organize the dependencies of your ecosystem. Layer design defines a dependency mechanism between your domains, thinking about the “blast radius” of each. The more at the pyramid’s base, the greater the impact and the more generalist its functionality. The further up the pyramid, the more specialist your functionality. Furthermore, the layers above it must depend only on the layers below it.

In the case of Uber, five layers were defined, but this can vary from company to company:

1. Infrastructure layer: provides functionalities that any service or functionality in your organization can use. This layer is not directly linked to the company’s business. It can be seen as databases, VPC, instances, networking, etc. At Mercado Livre, where I work, we can consider this layer to be Fury.
2. Business layer: provides business functionalities that any product can use. That is, it’s a functionality that forms part of the foundation of the company’s business. Services belonging to this layer must be strategically designed to support product expansion.
3. Product Layer: provides a particular functionality of a product category, regardless of how it will be presented (mobile, web, API,…).
4. Presentation: this layer aims to provide an experience for end users. For this, it uses the functionalities of the business layer but creates different forms of presentation that will depend on the person you want to attend.
5. Edge Layer: responsible for exposing services securely to the outside world.

Gateways

A gateway is a single entry to a set of services part of a domain. The article compares with an API Gateway, a theme we have already put into practice here.

Gateways play a crucial role in reducing the complexity of the ecosystem. In addition, they can facilitate future migrations and discoveries as it abstracts the internal complexity of domains.

Extension

Extensions are ways to extend a domain without changing its implementation and reliability. Two types of extensions are proposed in the article: logical and data.

Logical extensions are intended to allow logical extension of an underlying service. Data extensions provide a way to append new data to an interface in bloating the platform’s data models.

Benefits

Having understood the main concepts of DOMA, we can think of some benefits that its adoption can bring. Below is a list of some of these benefits mentioned in the original article (which I agree with):

Products and platforms: How layers are organized allows teams to focus on their specializations. In addition, the base layer hierarchy will enable you to create robust services allowing products to benefit and grow faster.

Reduced complexity: with the concepts of gateways and domains, the complexity of understanding the available resources decreases since there is now a single point of contact.

Future migrations: even with the concept of gateways and the abstractions that arise with their use, it is possible to think about refactoring domains without significant impacts on the entire ecosystem.

New lines of business and products: as previously mentioned, with the basis of the hierarchy of layers strengthened, it is possible to think about product innovation without a high cost.

Final Considerations

Many of the concepts and examples exposed so far were taken from the original article. However, I leave here my vision regarding the benefits, risks, and opportunities that DOMA can bring.

• DOMA is not a silver bullet. Your guidelines will not solve all the problems of your company’s architecture. As their domains are being defined, several issues will appear: services with duplicate contexts, nanoservices, integration fails, etc. See this as an opportunity to reduce costs and increase the robustness of your products.
• The domain is the essential concept of DOMA. For them to be well defined, your company must have its products/businesses minimally defined. Without this, domains can become confusing and layers without a solid hierarchy.
• As your company grows, the layers that make up the hierarchy base tend to grow. That is, new product variations and new capabilities must be created.
• Be careful with infrastructure and business layer services/domains. They need to be resilient and abstract certain complexities from the upper layers. This will make your products have a good experience and grow more efficiently (remember the “blast radius” of these layers).

In addition to the original Uber article, I share some other references on the subject, some of which are contrary to the use of DOMA:

• The Clean Architecture
• Building Domain Driven Microservices
• Apply Domain-Driven Design to microservices architecture
• Why Uber’s DOMA is WRONG
• Pattern: Decompose by subdomain

Well, that’s it, folks. I hope you enjoyed the article. See you soon!