Onion Architecture

Although there is no single silver bullet for every solution, most developers get locked into an architecture that doesn’t scale and changes becomes difficult and slow as the system grows.

Onion Architecture promotes a separation of concerns and a decoupled application.  Loose coupling makes it easier to upgrade or replace components without affecting other parts of the system.

This architecture is best suited for complex behavior and long-lived business applications. It may not be feasible for small websites.

Traditional Layered Architecture

Each layer depends on the layers beneath it and every layer will depend on some common infrastructure and utility services. 

Problems with Traditional Architecture

• Application is built on top of specific technologies that are sure to change
• Business logic is commonly added to the UI layer
• Transitive dependencies: makes it easy to take a dependency without putting much thought into it, and now it’s all over the code base.
• Components are harder to test
• Logic is easily scattered all over.  Locating code becomes a major effort.

The big drawback to this top-down layered architecture is the coupling that it creates.  If coupling prevents easily upgrading parts of the system, then the business has no choice but to let the system fall behind into a state of disrepair.  This is how legacy systems become stale, and eventually they are rewritten.

Onion Architecture

Onion Architecture promotes layers built on interfaces, and then injecting dependencies into those layers.  This allows dependencies to be easily interchanged and unit tests to be written against mock/fake objects.

The key tenets of Onion Architecture described by Jeffery Palermo are as follows:

• The application is built around an independent object model.
• Inner layers define interfaces. Outer layers implement interfaces.
• Direction of coupling is toward the center.
• All application core code can be compiled and run separate from infrastructure.

Application Core

• Business workflows, validation rules, domain model.
• Should not reference any external libraries.  No technology specific code.
• Defines all technical implementations as interfaces.
  • Application service interfaces provide decoupling of business logic.
  • Domain service interfaces provide object saving and retrieving behavior.

UI and other applications consume the Application Core. This includes ASP.NET MVC, Web API and test projects.

Infrastructure

Implementations of interfaces defined for application and domain services.    Infrastructure is where the EF DbContext is implemented, as well as things like logging, email sending, etc.

Dependency resolution / IoC containers are usually used to wire up core interfaces to infrastructure implementations which run at start up configuration.

References:  Jeffery Palermo, Matt Hidinger, Steve Smith, Robert C. Martin, Tony Sneed