Onion Architecture

Onion Architecture
Onion Architecture is an architectural pattern used in software development as a way to communicate a different architectural approach. It is an object oriented design concept emphasizing separation of concerns when building long lived business applications and applications with complex behaviors. Onion architecture eliminates the dependance on layers that are developed before or after it.

Origin
The name “Onion Architecture” was conceived by, Jeffrey Palermo, in an attempt to create another named architecture pattern among the industry providing professionals a common term to use when communicating a “different” approach in patterns. Many industry experts have come before with architectural patterns such the hexagonal architecture by Alistair Cockburn and Screaming Architecture by Robert Martin (Uncle Bob) bringing together the principal of hexagonal architecture, onion architecture and other patterns. Ward Cunningham and Martin Fowler have also been instrumental in architectural patterns. This was created to be used as a non-mainstream approach, not a breakthrough in new technique.

Principal
Onion Architecture’s main premise is that it controls coupling. The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core. In other words, all coupling is toward the center. This architecture is unashamedly biased toward object-oriented programming, and it puts objects before all others.

Key tenets of Onion Architecture:

• 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

The database is not the center. It is external. With Onion Architecture, there are no database applications. There are applications that might use a database as a storage service but only though some external infrastructure code that implements an interface which makes sense to the application core. Decoupling the application from the database, file system, etc, lowers the cost of maintenance for the life of the application.

Onion Architecture relies heavily on Dependency Inversion principle. The core needs implementation of the core interfaces. If these classes reside at the edge of the application, a mechanism for injecting the code at runtime so the application can do something useful.

It works well for applications in professional DevOps environments, and the model demonstrates how DevOps assets are organized in relation to the rest of the code.

In the very center we see the Domain Model, which represents the state and behavior combination that models truth for the organization. Around the Domain Model are other layers with more behavior. Layers outside the application core are ConferenceRepository and UserSession classes. These two classes each implement an interface closer to the center than itself. At runtime, our Inversion of Control container will look at its registry and construct the proper classes to satisfy the constructor dependencies of SpeakerController, which is the following:

public SpeakerController(IConferenceRepository conferenceRepository,

                        IUserSession userSession, IClock clock)
   : base(userSession)

{

   _conferenceRepository = conferenceRepository;
   _clock = clock;
   _userSession = userSession;

}

Martin Fowler, in his article Inversion of Control Containers and the Dependency Injection Pattern, helps to understand how pattern works. At runtime, the IoC container will resolve the classes that implement interfaces and pass them into the SpeakerController constructor. At this point in time, the SpeakerController can do its job.

Based on the rules of the Onion Architecture, the SpeakerController could use UserSession directly since it’s in the same layer, but it cannot use ConferenceRepository directly. It must rely on something external passing in an instance of IConferenceRepository. This pattern is used throughout, and the IoC container makes this process seamless.

Related Subjects

• Abstraction (Computer Science)
• SoC- Separation of Concerns
• Object Oriented Programming
• Coupling
• Dependency Inversion Principle
• Inversion of Control

What users are saying about the pattern

• Ayende Rahien’s
• Tony Sneed’s view and code sample
• StackOverflow

Further Reading

• Palermo, Jeffrey (2019). .Net DevOps for Azure. Apress. ISBN- 978-1-4842-5343-4
• Palermo, Scheirman, Bogard, Hexter, Hinze (2010). ASP .NET MVC 4 in Action. Manning Publications. ISBN 9781617290411 Search this book on .

References

Note: this architectural pattern, Onion Architecture, was conceived personally by the writer of this article. This article is not intended to persuade or convince a reader this architectural pattern is better over any others. It is designed to be used and implemented by professional developers as another option and in some cases in conjunction with existing patterns. The idea is made to developers to have another option in their toolbox.

This article "Onion Architecture" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Onion Architecture. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

---