onion architecture
DESCRIPTION
TRANSCRIPT
Putting business value back to the core of our applications
Onion Architecture
Traditional 3-layer Architecture
Inftrastructure / DAL
Core / BLL
UI
DB
Uti
litie
s /
Com
mon /
Share
d
nHibernate /
LINQ to SQL
ASP.NET
Log4Net
AutoMapper
StructureMap
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
Inverted Dependencies
Infrastructure / DAL
Core / BLL
UI
DB
Uti
litie
s /
Com
mon /
Share
d
nHibernate /
LINQ to SQL
ASP.NET
Log4Net
AutoMapper
StructureMap
Onion Architecture with Relative Sizes
Infrastructure (DAL)
Core(BLL)
UI
DB
Depend
ency
Reso
luti
on
(Uti
litie
s)
nHibernate /
LINQ to SQL
ASP.NET
Log4Net
StructureMap
AutoMapper
True loose coupling between layers/components
Limit re-write necessity over time, business value-adding logic is entirely self-contained
Application becomes very portable – next version of .NET or an entirely new language/platform
Business logic has no dependency tentacles (aside from your platform dependencies)
Architecture is more easily sustained over time, developers know exactly where components go, a lot of guesswork is removed
Infrastructure is free to use any data access library or external web services to do its work
UI and Data Access “layers” become much smaller, deal strictly with technology-related code
No more need for Common/Shared/Utilities project
Compiler enforces dependencies boundaries, impossible for Core to reference Infrastructure
Benefits of Onion Architecture
Dep
en
den
cy R
esolu
tion
User I
nterfa
ce
Infrastructure
ProductRepository<<class>>
Application Core
Application Services
Domain Services
Domain Model
IProductRepository
DB
IUserSession
HttpUserSession<<class>>
ProductsControllerBrowser hits: /Products/List
• 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
Draw application/system using concentric circles, can only take dependency on something provided in an inner layer
Take ownership of your interfaces
Declare the API of the dependency (abstraction) in the inner layer, push implementation outward
Direction of dependency is toward the center
Externalize all technology related code
Push complexity as far outward as possible
Guiding Principles
Dep
en
den
cy
Resolu
tion
User
Interfa
ce
Infrastructure
Application Core
Application Services
Domain Services
Domain Model
DB
Show us some code already…
Demo!