From layered architecture to DDD. My experience of migration and cutting of a monolith

Today we’ll talk about the architecture of backend applications and compare two popular ways of structuring projects: onion and DDD. I’ll tell you about the advantages of the second approach over the first and my recent experience of transferring a project to hexagonal architecture. This text is for those who have already worked with layered architecture and want more (for example, start working with microservices).

Let's start with layered architecture. Layered, also known as onion architecture, is an architecture in which we divide the entire application into layers. Each layer has its own function, its own clear purpose. For example, interaction with the database: such a layer should contain exclusively functions for interacting with the database, and nothing else. There should be no interaction with the client or any other functions.

Often in a layered architecture there are 3 main layers on the backend: for interaction with storage, application logic and a representative layer.

Here is a typical three-layer architecture, everything about it is quite simple. The request is passed through all layers, acquiring the final form (request in the storage), the response makes the return journey, turning into some format convenient for the client (JSON, XML, etc.).

I have been using this architecture for quite a long time in all my projects and in the startup in which I participate. In small pet projects, this approach really works and does not cause problems, but in larger projects, chaos begins.

One of the main principles of layered architecture is the ability to replace any layer with a similar one so that no other layer needs to be changed at all. But in reality, the more entities appear in a project, the more difficult it is to comply with it.

At first, too many dependencies appear, and it becomes increasingly difficult to control them. This implies the neglect of the monolith (after all, onion is a monolithic architecture). The load is not distributed correctly and the application is experiencing overload. Further, the layers begin to mix - it becomes more and more difficult to isolate the application logic. It becomes increasingly difficult to expand the application, dependencies make debugging hell, and development slows down greatly. Adding fuel to the fire are strict architectural patterns that limit the developer's capabilities. If you are reading this text, you have probably already encountered this. The same situation occurred in our project.

Obviously, in such a situation it is necessary to cut the monolith, switch to another architecture and introduce freer patterns. We chose DDD, it seemed like an obvious solution. DDD (Domain Driven Design, hexagonal architecture) is a microservice (although it can be used as a monolithic) architecture built on abstractions. If you only have experience working with layered architecture, then as a rough example you can imagine the same three-layer architecture, where instead of a layer of interaction with storage there is a layer of interaction with all technologies in general, and there is also a separate layer with abstractions. Abstractions are generally the main thing in DDD. These abstractions, as well as auxiliary tools and demonstration entities (templates, diagrams) are separated from the application, and as a result the architecture looks like this:

The main advantage of heskagonal architecture over layered architecture is expandability. It's much easier to implement new features, new parameters and new functions because there are fewer dependencies.

At first, this structure seemed completely illogical to me, but in the process of switching to DDD, I discovered that it became much easier to write, because the infrastructure was completely removed even from the lowest layer of the application, and there were fewer dependencies. There was even some kind of irrational relief and sudden freedom of action over each entity. This approach now seems to me even more logical than layered architecture.

But you need to remember that such an architecture does not make sense if there are 2-3 entities in the project, because DDD is used primarily as a microservice architecture in applications with a large number of dependencies, which simply cannot be in small pet projects with 2-3 entities. 3 essences. In some places, even a simple linear architecture is sufficient. And in general, using different technologies and practices just like that, unnecessarily, is bad practice, unless you decide to experiment to learn.

P.S. And you need to get hooked on TGC: https://t.me/dmkjfss

The above is the detailed content of From layered architecture to DDD. My experience of migration and cutting of a monolith. For more information, please follow other related articles on the PHP Chinese website!