Do you know the layers of the onion architecture?

The Onion Architecture is a software design approach that promotes a clear separation of concerns by organizing code into distinct layers. Each layer has a specific purpose, forming concentric circles around the core business logic, much like layers of an onion. This architecture encourages flexibility, testability, and resilience, ensuring that changes in outer layers have minimal impact on the core logic.

Download Onion Architecture PDF

Application Core (the grey stuff)

This should be the big meaty part of the application where the domain logic resides.

Domain Model

In the very centre, we see the Domain Model, which represents the state and behaviour combination that models truth for the organization and is only coupled to itself.

Repository Interfaces

The first layer around the Domain Model is typically where we find interfaces that provide object saving and retrieving behaviour. The object saving behaviour is not in the application core, however, because it typically involves a database. Only the interface is in the application core. The actual implementation is a dependency which is injected.

Business Logic Interfaces

Business logic is also exposed via interfaces to provide decoupling of business logic. Examples of where this is useful include substituting a FacebookNotificationService for an EmailNotificationService or a FedExShippingCalculator for a DHLShippingCalculator

Clients (the red stuff)

The outer layer is reserved for things that change often. E.g. UI and the other applications that consume the Application Core. This includes the MVC project. Any interface dependencies in factories, services, repositories, etc, are injected into the domain by the controller. This means any constructor-injected interfaces in domain classes are resolved automatically by the IoC container.

Dependencies

Dependencies are implementations of interfaces defined in Repository and Business Logic Interfaces and Domain. These classes are specific implementations and can be coupled to a particular method of data access, or specific service technology. e.g. this is where the EF DbContext is implemented, as well as things like logging, email sending, etc.

These dependencies are injected into the application core.

Because the Application core only relies on abstractions of the dependencies, it is easy to update them.

The Onion Architecture relies heavily on the Dependency Inversion principle and other SOLID principles. (Note: Onion Architecture has been replaced by Clean Architecture)

References

• Blog | Peeling Back the Onion Architecture
• Stack Overflow Questions | What type of architecture is this called?

---

Use SSW Data Onion to Generate your Code

To help make this process pain free, we've developed the SSW Data Onion to get you going and take away the boilerplate code you would normally need to write. Check out this cool video to see how it works:

Further Reading: Do You Use a Dependency Injection Centric Architecture?