Content
Onion Architecture requires a good understanding of software architecture principles and design patterns. Developers who are not familiar with these concepts may find it challenging to implement and maintain an Onion Architecture-based application. The Application layer contains the application-specific logic. It is responsible for coordinating the interaction between the Domain layer, the Infrastructure layer, and the User Interface layer.
Also, this layer is used to communicate between the UI layer and repository layer. The Service layer also could hold business logic for an entity. In this layer, service interfaces are kept separate from its implementation, keeping loose coupling and separation of concerns in mind.
Service Layer
One of the primary objectives of this architecture is to increase maintainability. To achieve this level of maintainability, there is significant work involved in firstly setting up the structure, and secondly maintaining it along the life of the system. Implementation of features may be slower, because there are multiple layers to get through. That’s why Jeffery Palermo recommends it for Enterprise Systems, and not smaller systems non-complex systems. Onion architecture might seem hard in beginning but is widely accepted in the industry. It is a powerful architecture and enables easy evolution of software.
The code samples are taken from an example repository, which you can find on GitHub. Ideally, the core domain should be independent of the framework being used. This may not be very straightforward, but it can be achieved through careful abstractions. Interactions between domain and persistence will follow a defined standard and will be independent of persistence details. Changes to frameworks and technologies can be made without influencing the core domain.
Resource Center
To build this layer, we create one more class library project named OA.Repo. This project holds both repository and data, context classes. It is an ASP.NET Core Web application in this sample but it could be a Unit Test or Web API project. It is the most external part of an application by which the end-user can interact with the application. It builds loosely coupled applications with in-built dependency injection in ASP.NET Core.
- Conceptually, we can consider that the Infrastructure and Presentation layers are on the same level of the hierarchy.
- The domain model is at the center of Domain-Driven Design or development, which thoroughly understands a domain’s procedures and regulations.
- Onion architecture is also applicable to microservices when viewing each microservice in isolation.
- We are using a Web API built with ASP.NET Core to create a set of RESTful API endpoints for modifying the domain entities and allowing consumers to get back the data.
- As it communicates via interfaces, it builds applications that are loosely coupled.
The clean architecture uses the principle of dependency inversion with the strict rule that dependencies shall only exist between an outer ring to an inner ring and never the contrary. The hexagonal architecture, or ports and adapters architecture, is an architectural pattern used in software design. It aims at creating loosely coupled application components that can be easily connected to their software environment by means of ports and adapters. This makes components exchangeable at any level and facilitates test automation. We simply move all infrastructure and data access concerns to the external of the application and not into the center. Jeffrey Palermo proposed this approach called Onion Architecture on his blog 2008.
What is the Onion Architecture?
Onion architecture layers interact to each other by using the Interfaces. C# programmers are drawn to Onion Architecture due to the dependency flows. If you are interested in learning more C# while working with the Onion Architecture, visit the TechRepublic Academy. It isolates adapters and interfaces in the outer rings of the architecture and leaves the inner rings for use cases and entities.
The end-user interacts with the application by this layer. To build this layer, we create an ASP.NET Core MVC web application named OA.Web. This project contains the user interface for both user and user profile entities database operations and the controller to do these operations.
There are several traditional architectures, like 3-tier architecture and n-tier architecture, all having their own pros and cons. All these traditional architectures have some fundamental issues, such as – tight coupling and separation of concerns. The Model-View-Controller is the most commonly used web application architecture, these days. It solves the problem of separation of concern as there is a separation between UI, business logic, and data access logic. The Model is used to pass the data between View and Controller on which the business logic performs any operations.
Programming with Palermo
It is essential that within an individual layer all components work at the same level of abstraction. The relaxed or flexible layering is less restrictive about the relationships between layers. The advantage onion architecture of this approach is usually more flexibility and performance but this is paid for by a loss of maintainability. We’ve shown you how to implement the Domain layer, Service layer, and Infrastructure layer.
Just like an onion, your levels are separate layers that do not intermingle, they are their own separate layers of coding. Because of the top to down coupling, you can peel layers off from the outside without ever effecting your inner layers of coding. By forcing your coding to couple with only the layer under it, you are able to place key dependencies closer to the core to reduce downtime and increase system stability. The domain, although the most important part of the application, tends to be also the smallest in terms of code size. As a developer, you need to design a user related business logic, which will persist in a database.
Each layer has a specific responsibility, and there is a clear separation of concerns between the layers. The User Interface layer is responsible for presenting the information to the user and receiving input from the user. It can be a web application, a mobile application, or a desktop application. The User Interface layer depends on the Application layer and interacts with the user using the services and interfaces provided by the Application layer.
Onion Architecture layers are connected through interfaces. I have created one small project in Visual Studio which explains the structure of Onion Architecture. The main purpose of Clean Architecture is to allow the business to adapt to changing technology and interfaces.
Taking Care of Database Migrations
Since the domain changes the most — here is the place where you put all the new features, and business requirements — it should be as easy as possible to modify and test. This doesn’t mean of course, that the domain classes can’t have any dependencies. Like it the example above — the code uses Lombok annotations, generating the boilerplate which otherwise needs to be written by the programmer. The main difference between “the classic” three-tier architecture and the Onion, is that every outer layer sees classes from all inner layers, not only the one directly below.
This view model is also used for adding or editing a user. The Entities Domain layer is a core and central part of the architecture. So first, we create “OA.Data” project to implement this layer. This project holds POCO class and fluent API configuration for this POCO classes. This architecture relies heavily on the Dependency Inversion Principle. The UI communicates to business logic through interfaces.
Create and Configure Azure Network Watcher
Application Services interact with other services to fulfil the client’s request. Let’s consider the use case to create an order with a list of items. We first need to calculate the price including tax computation/discounts, etc., save order items and send order confirmation notification to the customer. The application services can be only invoked by Infrastructure services. Outer layer data formats should not be used by inner layers.
Disadvantages of N-Layer Architecture
It is particularly useful for complex applications that require flexibility and scalability. By following the principles of Onion Architecture, developers can create high-quality applications that meet the needs of their users and stakeholders. The more involved approach is to define compilation modules representing the layers. Its disadvantage is a more complicated build structure and setup of your build tool of choice. On the other side though, having the compiler on your side is very helpful, and prevents the above-mentioned issue. The direction of the dependencies between layers is clearly defined in the module build files.
As we have seen, all three architectural styles share the principles of loose coupling and attempt to minimize moving parts by properly layering the application. In essence, MVC resolves the separation of concerns problem, but the tight coupling problem remains. Loose Coupling — It denotes the independence of two objects and the fact that one object can use another without becoming dependent on it.