The outermost layer of the onion is the layer that is directly outside the application core. The purpose of this layer is to externalize infrastructure components, example SQL Database, Azure Cosmos Database, Azure Service Bus etc. If the implementation of a service consists of things that change often, then only the interface of this service will be in this layer. The actual implementation of the service will be found in the outer layer of the onion.

Each layer acts as modules/package/namespace within the application. Improves overall code testability as unit tests can be created for separate layers without impacting other modules. The main issues we faced were related to maintaining the low connectivity of microservices. That’s why it was difficult to immediately divide the functionality into the necessary microservices.

Working with Blazor in C#

The architecture does not depend on the data layer, as in a traditional three-tier architecture; it depends on real domain models. This architecture ensures that the application core doesn’t have to change as User Interface and Infrastructure services. Infra and UI are things that change with some regularity. So, it’s important to have an architecture in which you can swap the technology without mess up all around the application. To keep an application a long-life it’s important to have business logic and infrastructure service concerns independent from business logic. This architecture follows the Dependency Inversion Principle as well as Domain-Driven Design DDD. Data model and business logic at the center, instead of infrastructure concerns .

The obvious advantage of the Onion architecture is that our controller’s methods become very thin. We moved all of the important business logic into the Service layer. The Onion architecture is a form of layered architecture and we can visualize these layers as concentric circles.

Infrastructure Layer

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. The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core. This architecture is unashamedly biased toward object-oriented programming, and it puts objects before all others. They represent the business models, containing the business rules from it’s domain.

• Dependency Resolution needs to know where all of the implementations are so that it can resolve them when it needs to.
• I respect all the other implementations and perspectives.
• The idea is to have all of your domain objects at this core.
• Inside the UI you would use the DAL or Service implementations through the defined interfaces.
• If we need anything from an external system or service, we can just create an interface for it and consume it.
• Because it depends on the layers below it in the hierarchy, it can only call the methods that are exposed by the lower layers.

This rule of thumb usually can help you distinguish between these different kinds of rules. Your Domain models can have Value objects in their attributes, but the opposite is not allowed. It’s not so clear if this behavior should be implemented by the Account model, so you can choose to implement it in a Domain Service. Domain-driven design is the concept that developers and domain experts should use the same names both in code and business domain. It’s a software that any developer should be able to do improvements and fixes without worrying about breaking something under the hood.

domain-driven-hexagon

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. By separating the application into layers, the system becomes more testable, maintainable and portable. It helps easy adoption of new frameworks/technologies when old frameworks become obsolete. Similar to other architectural styles like Hexagonal, Layered, Clean Architecture, etc. it provides a solution for common problems. Divide the application into different modules/projects each responsible for a layer in onion architecture.

The Domain Interfaces are implemented in the Supermarket.Core project. Since a Domain Interface acts on an Entity, it should be considered pure business logic. The CartItem class in the Supermarket.Core project is such a class. It happens to be an abstract class that has two implementations, QuantityBasedItem and WeightBasedItem, which are also considered Domain Entities. I recently built a small ASP.NET Core API that shows my preferred approach to testing cloud apps. I designed the application using the https://globalcloudteam.com/, which I’d been wanting to get more familiar with in the context of a real-world application.

The Onion Architecture relies heavily on the Dependency Inversion principle. In this layer, we normally put the repository access, migrations, and all the infrastructure services. The advantage of having this layer separately is, you can swap the technology without touch the other layers. This architecture should be used when creating services that deal with business rules. When you are creating a software that does not deal with business rules, this architecture won’t fit well. It would be really cumbersome to implement, for example, a simple gateway using Onion Architecture.

Create and Configure Azure Network Watcher

Interfaces define behaviour contracts and stand as foundations amongst the layers. This approach is biased towards Object Oriented Programming . However it’s principles can still be applied in a wider sense.

By now you’ll have noticed that my onion is slightly different from other explanations that can be found online. Some of this is my own interpretation of the rules, and some of it is my pragmatic way of implementing it. Onion architecture became obvious to me once I understood DDD and necessary design patterns such as MVC, Dependency injection, Repository/Service, ORM. But in my opinion, organizing projects can be different and trivial when there is full understanding of the architecture.

Onion Architecture

The concrete implementation of a repository is implemented outside the application core, thus decoupling the actual database from the application core. The domain layer is in the very center of the onion architecture. It represents the state, processes, rules and behavior of an organization. Since all coupling in an onion architecture is toward the center, the domain is only coupled to itself. The popularity of microservices is growing due to the range of benefits they offer to developers and businesses.

It provides better maintainability as all the code depends on deeper layers or the centre. 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.

I’ve found that it leads to more maintainable applications since it emphasizes separation of concerns throughout the system. I must set the context for the use of this architecture before proceeding. This architecture is not appropriate for small websites. It is appropriate for long-lived business applications as well as applications with complex behavior.

Implementation of Onion Architecture

Dependency Injection is a necessary evil with this architecture. It causes us to rely heavily on something quite external that binds the entire application together and allows it to function at run-time. That being said, it’s not a big deal and it does not outweigh the pros. In some cases though, it might make more sense to use a Domain Interface to encapsulate business logic outside of the entity.

This means that in the Domain layer, we are not concerning ourselves with infrastructure details such as the database or external services. The circles represent different layers of responsibility. In general, the deeper we dive, the closer we get to the domain and business rules. The outer circles represent onion structure mechanisms and the inner circles represent core domain logic. The outer layers depend on inner layers and the inner layers are completely unaware of outer circles. Classes, methods, variables, and source code in general belonging to the outer circle depends on the inner circle but not vice versa.

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. Externalizing the database can be quite a change for some people used to thinking about applications as “database applications”.

Interfaces

The onion architecture, introduced by Jeffrey Palermo, overcomes the issues of the layered architecture with great ease. With Onion Architecture, the game-changer is that the Domain Layer is at the Core of the Entire Application. In this approach, we can see that all the Layers are dependent only on the Core Layers.

Layers

Note that, ideally, you should always try to implement behaviors in Domain Models to avoid falling in the Anemic Domain Model pitfall. By isolating your domain logic, it becomes easy to test, and easier to maintain. This rule also exists in other similar architectures, such as Clean Architecture.

That’s why Jeffery Palermo recommends it for Enterprise Systems, and not smaller systems non-complex systems. This layer contains the implementation of the behaviour contracts defined in the Model layer. The name Onion Architecture was originally coined by Jeff Palermo, but has since gone under lots of other pseudonyms.