Domain Driven Design: the layered arch

The layered arch, more traditionally, the 3-tier arch is a trending in the enterprise technology. Every company you go, you gonna see, by default, this type of architecture, using mostly an anemic design, but all the nomenclatures used have origins in DDD. We use layers here like the process of decantation: we need a good picture and level of isolation to decouple our business rules from the application needed code, and we use layering to draw clearly domain models, not in anemic fashion, to implement business rules more easily. Follow this infographic I made to understand more: Click here to see in full scale I detailed the explanation more below: Layered Arch: How it is made today The default and classic architecture in the majority of systems comprise in a generic layered architecture with 3 layers, and a separate (or in the same system boundary) layer that represents the user interface. This user interface often is a React ou Angular app, that communicates with the backend application using an integration layer. The user interface and the integration layer are referred as Presentation Layers, because is where the system receives input and throw out the outputs in response to requests. The entire system uses a very poor anemic model, where we have plain data, with no objects and no related behavior, or no related functions, and a bunch of procedures that will modify these data. These procedures comprises business rules that make validation and transformation of data, and pass the data to a layer to communicate the changes, data creation or validation to a database layer, or another services: Making our architecture more rich We can make a set of steps to make our architecture more rich and make it communicate more intent, by updating our paradigms and how we think about it. The first thing that I think is that, although we have guidelines in it, no system will repeat architecture schemas. By default we want to make use of the most encapsulation possible in our system, that leads to decouplement and make it more easy to change. Modularizing the system by feature, and not by infrastructure, permits us to make the most from it, and not only that, we can tie the behavior necessary to the data structures, make the system more easy to understand and modify. We are not gonna target here only object oriented paradigms, but functional paradigms too, by not placing the functions that act on data structures too far, but colocating them next to each other and taking advantage of scoping to limit the broadness of agency of each them: By now, we promote anemic models to domain models and make the application manage them accordingly. The communication to other features necessary to the actual domain is made more clear, and the boundaries can be better understood now.

Mar 6, 2025 - 05:31

The layered arch, more traditionally, the 3-tier arch is a trending in the enterprise technology.

Every company you go, you gonna see, by default, this type of architecture, using mostly an anemic design, but all the nomenclatures used have origins in DDD.

We use layers here like the process of decantation: we need a good picture and level of isolation to decouple our business rules from the application needed code, and we use layering to draw clearly domain models, not in anemic fashion, to implement business rules more easily.

Follow this infographic I made to understand more:

Click here to see in full scale

I detailed the explanation more below:

Layered Arch: How it is made today

The default and classic architecture in the majority of systems comprise in a generic layered architecture with 3 layers, and a separate (or in the same system boundary) layer that represents the user interface. This user interface often is a React ou Angular app, that communicates with the backend application using an integration layer.

The user interface and the integration layer are referred as Presentation Layers, because is where the system receives input and throw out the outputs in response to requests.

The entire system uses a very poor anemic model, where we have plain data, with no objects and no related behavior, or no related functions, and a bunch of procedures that will modify these data. These procedures comprises business rules that make validation and transformation of data, and pass the data to a layer to communicate the changes, data creation or validation to a database layer, or another services:

Making our architecture more rich

We can make a set of steps to make our architecture more rich and make it communicate more intent, by updating our paradigms and how we think about it.

The first thing that I think is that, although we have guidelines in it, no system will repeat architecture schemas. By default we want to make use of the most encapsulation possible in our system, that leads to decouplement and make it more easy to change. Modularizing the system by feature, and not by infrastructure, permits us to make the most from it, and not only that, we can tie the behavior necessary to the data structures, make the system more easy to understand and modify.

We are not gonna target here only object oriented paradigms, but functional paradigms too, by not placing the functions that act on data structures too far, but colocating them next to each other and taking advantage of scoping to limit the broadness of agency of each them:

By now, we promote anemic models to domain models and make the application manage them accordingly. The communication to other features necessary to the actual domain is made more clear, and the boundaries can be better understood now.