Organization & Future-proofing Your Code 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. 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 that long after they are developed. The main premise behind onion architecture is the fundamental concept of pushing your code and having as few dependencies in your code as possible. If the code lasts more than five years, this is a significant accomplishment. The way technology is growing, it becomes increasingly more difficult for software to stay up to date. Platforms that existed ten, fifteen, and twenty years ago are becoming increasingly obsolete. This concept of decoupling is a big driver behind software to live for more than 5 years. At the core of your onion is your business logic with the onion-based architecture, the engine if you will. Around that, you can add dependencies. There are many levels in this configured pattern, or literally layers like an “onion.” The architecture does not intermingle core code with the external outside code. As you can peel off the outer layers, it doesn’t affect the inner layers. A classic example is Microsoft’s data access stack, which tends to change every few years. The data access layer is represented by a number of repository interfaces. Now, you can swap out LINQ to SQL with NHibernate (or any ORM) without breaking existing parts of the application. This approach is used to decouple things like configuration and logging so they convert into replaceable mechanisms. The biggest difference between traditional architecture and onion architecture is any outer layer can directly call any inner layer. Infrastructure is pushed out to the edges where no business logic code couples to it. The code that interacts with the database will implement interfaces in the application core. The core code does not care about the external code and doesn’t need to know what user interface or database, only the class or form of data. The code that interacts with the database will implement interfaces in the application core. The application core is coupled to those interfaces but not the actual data access code. This way, we have the ability to change code in any outer layer without affecting the application core. We include tests because we any long-lived. Onion-based B2B architecture can drastically streamline your development processes. Please contact a consultant at Clarity today to learn how we can assist you in your team’s execution.