By Shabbir Akolawala
Problem with Traditional 3-layer architecture
Over the years, 3-tier architecture has been the norm in architecting the enterprise architecture. There’s nothing wrong with n-tier architecture, but over the year, with library explosion, it has been difficult to keep up with just logical layer separation, where we are trying to solve different problem.
Let first understand the problem in following, conventional 3-tier architecture. In traditional 3 tier architecture, Presentation (UI) talks to business layer and business layer talks to Data access layer
Direct call to Data access from the UI isn’t allowed in the 3-tier architecture; as layers are stack one over another.
So far so good, but embracement of new UI architecture like MVC (Model view controller) find it hard to fit in the single layer constrain like UI shouldn’t talk to data access layer
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
Impede with traditional architecture
- 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
In order to solve, the problem, better way would be to invert the dependencies. This would loosen coupling between layers/component
Here comes the Onion architecture. In it application core layer consist of core domain entities, like model, interfaces, services, business logic which are related to business problem, and free from infrastructure concerns.
Onion architecture consists of three principles
- Dependency resolution
Most of the infrastructure concerns are outside your application boundary and are related to infrastructure. Persistence data concern (RDMS, NoSQL), Notification concerns (Email, SMS), transport security concerns (http, SSL), Authentication (windows authentication, form). These concerns shouldn’t dictate the business rules and shouldn’t creep into all the layers. Hence, all infrastructure components are represents via abstract interface in Application Core.
Concrete implementation of the interfaces would be injected into business and domain services at the Runtime via dependency injection at runtime.
Onion architecture uses to draw application/system using concentric circles, can only take dependency on something provided in an inner layer.
It has following triads
Direction of dependency is toward the centre
Externalize all technology related code
Push complexity as far outward as possible
Take ownership of your interfaces
Onion architecture has been taken as architectural spike and has been implemented in ICT projects
Approved Training Course
General benefits observe after following the architecture guideline
Solutions become clean with distinct line between the responsibilities
It easier to implement cross cutting concerns like tracing and caching without polluting the core methods
Business logic become guileless, straight forward and focus on domain problem rather than infrastructure concerns
It tranquil automate unit testing due to loose coupling of components
It easier to extend component without breaking the dependency