Onion Architecture Lets slice it like a Pro by Ritesh Kapoor Expedia Group Technology

CQS also tends to imply immediate consistency between the read and write models, while CQRS often implies eventual consistency between the read and write models. You should use different projects when you need different deliverables. Layers do not necessarily need to be in different projects, especially in small applications. These days we have a different idea of what should go in a layer than 30 years ago, and we are more careful about where we put domain logic, presentation logic, and so on. But the architectural principles are all essentially the same. The answer is, as always, “it depends”, but I would argue the extra abstraction layer is definitely worth the effort for projects of sufficient size and scope.

• Let’s look at one of the most popular Architecture in ASP.NET Core Applications.
• Naturally, maybe you want to start the development by the database, but it’s a mistake!
• Using this approach, we can encapsulate all of the rich business logic in the Domain and Service layers without ever having to know any implementation details.
• This way we achieve application robustness as any of the boundaries might be replaced by re-implementing ports or adapters.

Navigate to ../Startup.cs and add these lines to the ConfigureServices method. Next, let’s go to the Infrastructure Folder and add a layer for Database, . To keep things simple but demonstrate the architecture to the fullest, we will build an ASP.NET Core Web API that is quite scalable. For this article, Let’s have a WebApi that has just one entity, Product. We will perform CRUD Operations on it while using the Onion architecture. In N Layer Architecture, the Database is usually the Core of the Entire Application, i.e It is the only layer that doesn’t have to depend on anything else.

IAPIDateFormatter implementation must know how API wants to receive the date objects. Would it be UTC timestamp, or should it be sent with user’s timezone offset? With the offset, set in the global runtime configuration? It totally depends on a logic of the application and on a logic of the web server.

Do We Need Every Layer?

The popularity of microservices is growing due to the range of benefits they offer to developers and businesses. In this article, I will tell you about my experience of using onion architecture with a harmonized combination of DDD, ASP.NET Core Web API and CQRS for building microservices. Yes, you can definitely use Repository Pattern alongside Onion Architecture. It gives a better separation between your actual database of choice and your data access code.

As a close cousin of Hexagonal, Onion Architecture is certainly very powerful, but the extent to which we’ll apply its principles should be carefully considered. The Service layer holds interfaces with common operations, such as Add, Save, Edit, and Delete. 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. At the center part of the Onion Architecture, the domain layer exists; this layer represents the business and behavior objects.

Onion Architecture 🧅

Any developer, familiar with the domain, should be able to understand the code, and easily know where to change things. So, we can see onion architecture that it’s important to build maintainable software. We should be able to build a software that can be maintained by future developers.

It greatly depends on the complexity of the application and the size of the project to divide source code into multiple modules. In a microservice architecture, modularisation may or may not make sense depending upon the complexity and use-case. Low coupling in which one module interacts with another module and does not need to be concerned with the other module’s internals.

Why Onion Architecture?

Adding a layer of abstraction for ORM or cloud provider are the best example of faux abstraction, the one that add no good but unnecessarily complicates the codebase. There are special cases when you need but again in most cases it makes no sense. Database migration should be handled by your CI/CD pipeline.

The Onion architecture is also commonly known as the “Clean architecture” or “Ports and adapters”. These architectural approaches are just variations of the same theme. ASP.NET Core offers Health Checks Middleware and libraries for reporting the health of app infrastructure components.

To put it simply, every action in Web API is either a request or a command , but it shouldn’t do both. Consequently, each API method is divided into requests and commands. Independence — each microservice should function independently from others. Aliaksandr is a Senior .NET developer at SaM Solutions with 13 years of experience. Being a Microsoft certified engineer, he specializes in web development and has experience in creating desktop and mobile solutions.

Onion Architecture In ASP.NET Core MVC

This architecture provides a better way to build applications for better testability, maintainability, and dependability on the infrastructures like databases and services. There are two types of coupling – tight coupling and loose coupling. Organising our application in layers helps in achieving separation of concerns.

The OA.Data project holds three entities, one is the BaseEntity class that has common properties that will be inherited by each entity. The code snippet, mentioned below is the BaseEntity class. To implement the Onion Architecture in the ASP.NET Core application, create four projects as described in the above section.

Presentation project and configure them with the framework. They are going to be treated the same as if they were defined conventionally. But how are we going to use the controller if it is not in the Web application? Well, let us move on to the next section to find out. Great, we have seen how to implement the Presentation layer.

Constructing the Onion

Now, we define the configuration for the UserProfile entity that will be used when the database table will be created by the entity. The code snippet is mentioned below for the UserProfile mapping entity (UserProfileMap.cs). Now, we define the configuration for the User entity that will be used when the database table will be created by the entity. The following is a code snippet for the User mapping entity (UserMap.cs).

The Essence of Onion Architecture

However, we are not doing anything useful at the moment with the transaction so from this and following the layers of Onion Architecture we need to define our Domain Services layer. Changes to frameworks and technologies can be made without influencing the core domain. For example, you can easily replace SQL with MongoDB without affecting the core. We now know that Onion Architecture has a significant role in implementing a domain-driven design.

When doing software development, one of the most important things to have in mind is that your software should always be evolving. It will always be maintained, evolved, receiving new features, improvements, and bug fixes. Not easy to understand for beginners, learning curve involved. Architects mostly mess up splitting responsibilities between layers. Russ Milesdid a presentation about his Life Preserver ideas, based on the Hexagonal architecture, last year. Hello, I am a .Net architect working for a very very very wealthy company in the USA.

If you are looking to test the entire system then that would be an end-to-end test that would be performed. Onion Architecture is comprised of multiple concentric layers interfacing with each other towards the core that represents the domain. The architecture does not focus on underlying technology or frameworks but the actual domain models.

Layers in Onion Architecture

Using different projects for different layers is only ever coincidentally a good idea. You’d have to have a very large project before doing that made any sense, in which case moving the application into a more service-based architecture might well be a better choice. This will be an Empty API Controller which will have API Versioning enabled in the Attribute and also a MediatR object. We will not have to re-define the API Versioning route or the Mediator object. But we will just add the BaseAPI Controller as the base class. We will have to register IApplicationDBContext and bind it to ApplicationDbContext, right?