Onion-based Software Architecture


Where did Onion Architecture Originate?

The name, “Onion Architecture” was coined by Jeffery Polermo in 2008 to describe a pattern used in development architecture. At the time of inception, he defined four tenets of the architecture:

  1. The application is built around an independent object model
  2. Inner layers define interfaces, while the outer layers implement those interfaces
  3. The direction of coupling is towards the center
  4. All application core code can be compiled, and can run separately from the infrastructure

 

Although there has been significant adoption of this pattern,” said Polermo in a 2013 speech, “I have received countless questions about how to implement it in various environments.” He continues to explain that he mostly gets asked about how it relates to a domain-driven design. “First,” expounds Polermo, “onion architecture works well with and without DDD patterns. It also works well with CQRS, forms over data and DDD. It is merely an architectural pattern where the core object model is represented in a way that does not accept dependencies on less stable code.”


What is Onion Architecture?

Previously, we used Microsoft’s data access stack as an example of onion-based architecture. Today, we can refer to Microsoft’s platform as an onion-based architecture that is used with both ASP.NET and Visual Studio successfully. Onion architecture is a software architectural configuration to maintain libraries and dependencies on the extremities of a software system while sustaining a strong and cohesive system core. Developing a system core which is both stable and efficient is essential when basing a system’s architecture to that of an onion. By emphasizing the separation of concerns and dependencies in this layered fashion, this will increase the quantity of maintainable applications running simultaneously. If onion based architecture is set up properly, it is intended to provide insurance against the evolution of technology that can make products obsolete not long after they are developed.


Benefits of an Onion Architecture

  • Better sustainability over time with simplified indexing
  • Reduce dependencies within your platform
  • Loose coupling between layers
  • Flexible infrastructure enabling free range use of data
  • Removes the need for common or shared documents/projects
  • Data Access and UI layers are reduced in size and complexity

Designing an Architecture

First, onion architecture works well with and without DDD patterns. It also works well with CQRS, forms over data and DDD. It is merely an architectural pattern where the core object model is represented in a way that does not accept dependencies on less stable code.

When designing the architecture of a building there are many aspects you need to consider. Will our base provide enough support for every floor, what if support beams A and B collapse, will floor C remain standing? These same questions can apply to software architecture as well. Developing an architectural pattern in which your dependencies are on the extremities and your system core is built strong, if dependencies A and B collapse, dependency C will remain active because of the strong system core. The objective behind the onion pattern is to push your code and to have as few dependencies in your code as possible.

At the system’s core you will have your business logic, surrounding your core you can add your dependencies. 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.