Onion Architecture, the concept introduced by the Jeffery Palermo in 2008 with a aim to make the application loosely coupled and with proper separation between the folders and the different areas of concern in the application. This makes the development easier, the testing of the application easier, the maintenance becomes easier.
11. @IamVMac
• Very easy for developers over time to put more and more business logic in the UI layer
• Counter-productive to build your application on top of a specific technology that is sure to
change over time
• Logic is easily scattered all over, locating code becomes a major effort.
• Developers over time struggle to determine where code should go… DAL? BLL? Utilities?
• Business logic has many tentacles extending from it (directly and indirectly)
• Library explosion: Makes it easy take a dependency without putting much thought into it, and
now it’s littered all over the code base
Problems with Traditional Architecture
12. The Onion Architecture to rescue
• Quoted by Jeffrey Palermo in 2008.
• relies heavily on the Dependency Inversion principle.
• The database is not the center. It is external.
@IamVMac
14. @IamVMac
•Everything unique to the business: Domain model, validation rules,
business workflows
•Defines all technical implementation (non-business) needs as
interfaces
•CANNOT reference any external libraries
•NO technology specific code
Core
•Provide implementations for Core interfaces
•Call web services, access a database
•CAN reference external libraries to provide implementations
•ONLY technology specific code (non-business) belongs in
infrastructure
Infrastructure
•Very thin layer, has no logic of its own
•Wires up Core interfaces to Infrastructure implementations.
•Runs startup/configuration logic
Dependency
Resolution