Onion architecture. Part 1
Earlier, I mentioned several times about a special type of architecture, which I call onion architecture. This architecture is ideal for applications with a long life cycle and complex business logic. I believe that its use in such projects leads to excellent results, as a result of the emphasis initially placed in the architecture on the separation of various aspects of the application. The onion architecture pays special attention to the description of the system behavior in terms of contract programming and the removal of the infrastructure code to external modules. In the diagram below, you can see a graphical representation of the traditional “layered” architecture. This is a very popular approach that is used in various variations in the many projects I have seen.
Each next layer is closely connected with its neighbors and depends on the used infrastructure modules and services. The main disadvantage of multi-layered architecture is the high connectivity it generates. As we know, the worst manifestation of high connectivity is the penetration of UI elements and business logic into the data access layer. In projects using multi-layer architecture, the UI remains closely associated with the data access layer. Passing addiction remains addiction. The UI layer cannot function separately from the business logic layer, just as the business logic layer is not able to function separately from the data access layer. I deliberately ignore issues related to infrastructure, since infrastructure tends to change from project to project. The data access layer is constantly changing. Historically, data management approaches are updated at least once every three years. Therefore, in applications with a long life cycle, you need to be prepared for the fact that after three years you have to make changes to the data access layer. If a high connectivity prevents replacing outdated modules independently of each other, the whole system can go into a state of decline and the team will have nothing left but to completely rewrite it.
I propose a new approach to building applications. To be honest, it is not entirely new, but I propose to give it a name and fix it in line with other architectural patterns. Patterns are useful because they provide developers with a common vocabulary to simplify communication. Onion architecture has many aspects, and we need to give it a name for more effective communication. The diagram below shows the onion architecture.
')
Its key feature is in coherence management. The fundamental rule is that any application module may depend on modules closer to the center of the bulb, but cannot depend on more distant ones. In other words, any connectedness should be directed to the center of the bulb.
Onion architecture to OOP and puts objects above any other aspects of the application. In the center is the domain model of the application. There are other layers with additional business logic around the domain model. The number of layers in an application can vary, but the domain model must always remain in the very center and, since any connectedness is directed toward the center, the domain model is only connected with itself. The first layer around the domain model is the place where the interfaces of the repositories are usually located, ensuring the preservation and retrieval of objects. It should be noted that the process of saving objects is outside the application kernel, since this process usually involves interaction with the database server, and only interfaces are located in the center of the kernel. On the outer radius of the application are UI, infrastructure and tests. The outer layer is reserved for elements that change frequently. These elements must be isolated from the application kernel. At the very edge, there are classes that implement the interfaces of the repositories. These classes are closely related to a specific data access technology, and that is why they must be moved outside the core of the application.
Onion architecture is based on the principle of dependency inversion. The application requires implementations of the interfaces located in the kernel, and since specific implementations are located on the external radius of the application, the application also needs a mechanism for injecting dependencies.
The database is not located in the application center. Moving the database engine from the kernel to a separate module can be a serious step for people thinking of applications solely in the context of interacting with data sources. Of course, applications can use databases to save objects, but only through a layer of infrastructure code that implements the interfaces used in the application kernel. Disconnection between application and database, file system, etc. reduces the cost of supporting the application throughout its life cycle.
Alistair Cockburn in his blog once wrote on the topic of Hexagonal architecture . The hexagonal and onion architecture is based on general principles: transferring infrastructure to external modules and writing adapters to them. I plan to write more on the use of onion architecture when building enterprise-level applications. I still remain in this environment and continue the discussion on onion architecture in this context.
From the translator. This post is the first of a series of posts by Jeffrey Palermo on onion architecture. If habrasoobschestva have an interest, I can do the translation and the rest of the parts.
Each next layer is closely connected with its neighbors and depends on the used infrastructure modules and services. The main disadvantage of multi-layered architecture is the high connectivity it generates. As we know, the worst manifestation of high connectivity is the penetration of UI elements and business logic into the data access layer. In projects using multi-layer architecture, the UI remains closely associated with the data access layer. Passing addiction remains addiction. The UI layer cannot function separately from the business logic layer, just as the business logic layer is not able to function separately from the data access layer. I deliberately ignore issues related to infrastructure, since infrastructure tends to change from project to project. The data access layer is constantly changing. Historically, data management approaches are updated at least once every three years. Therefore, in applications with a long life cycle, you need to be prepared for the fact that after three years you have to make changes to the data access layer. If a high connectivity prevents replacing outdated modules independently of each other, the whole system can go into a state of decline and the team will have nothing left but to completely rewrite it.
I propose a new approach to building applications. To be honest, it is not entirely new, but I propose to give it a name and fix it in line with other architectural patterns. Patterns are useful because they provide developers with a common vocabulary to simplify communication. Onion architecture has many aspects, and we need to give it a name for more effective communication. The diagram below shows the onion architecture.
')
Its key feature is in coherence management. The fundamental rule is that any application module may depend on modules closer to the center of the bulb, but cannot depend on more distant ones. In other words, any connectedness should be directed to the center of the bulb.
Onion architecture to OOP and puts objects above any other aspects of the application. In the center is the domain model of the application. There are other layers with additional business logic around the domain model. The number of layers in an application can vary, but the domain model must always remain in the very center and, since any connectedness is directed toward the center, the domain model is only connected with itself. The first layer around the domain model is the place where the interfaces of the repositories are usually located, ensuring the preservation and retrieval of objects. It should be noted that the process of saving objects is outside the application kernel, since this process usually involves interaction with the database server, and only interfaces are located in the center of the kernel. On the outer radius of the application are UI, infrastructure and tests. The outer layer is reserved for elements that change frequently. These elements must be isolated from the application kernel. At the very edge, there are classes that implement the interfaces of the repositories. These classes are closely related to a specific data access technology, and that is why they must be moved outside the core of the application.
Onion architecture is based on the principle of dependency inversion. The application requires implementations of the interfaces located in the kernel, and since specific implementations are located on the external radius of the application, the application also needs a mechanism for injecting dependencies.
The database is not located in the application center. Moving the database engine from the kernel to a separate module can be a serious step for people thinking of applications solely in the context of interacting with data sources. Of course, applications can use databases to save objects, but only through a layer of infrastructure code that implements the interfaces used in the application kernel. Disconnection between application and database, file system, etc. reduces the cost of supporting the application throughout its life cycle.
Alistair Cockburn in his blog once wrote on the topic of Hexagonal architecture . The hexagonal and onion architecture is based on general principles: transferring infrastructure to external modules and writing adapters to them. I plan to write more on the use of onion architecture when building enterprise-level applications. I still remain in this environment and continue the discussion on onion architecture in this context.
From the translator. This post is the first of a series of posts by Jeffrey Palermo on onion architecture. If habrasoobschestva have an interest, I can do the translation and the rest of the parts.
Source: https://habr.com/ru/post/233747/
All Articles