What is Onion Architecture ?

As we said in the introduction, the concept of Onion Architecture is closely connected to two other architectural styles – Layered and Hexagonal. Similarly to the Layered approach, Onion Architecture uses the concept of layers, but they are a little different:

• Domain Model layer, where our entities and classes closely related to them e.g. value objects reside
• Domain Services layer, where domain-defined processes reside
• Application Services layer, where application-specific logic i.e. our use cases reside
• Outer layer, which keeps peripheral concerns like UI, databases or tests

Those layers when presented as circles, each wrapping around the previous one, form the famous “onion”:

Benefits of an Onion Architecture

• Plays well with DDD – that should not be a surprise for an architecture that builds everything on top of a domain model
• Directed coupling – the most important code in our application depends on nothing, everything depends on it
• Flexibility – from an inner-layer perspective, you can swap out anything in any of the outer layers and things should work just fine
• Testability – since your application core does not depend on anything else, it can be easily and quickly tested in isolation

Drawbacks of an Onion Architecture

• Learning curve – I don’t know why, but people tend to mess up splitting responsibilities between layers, especially harming the domain model
• Indirection – interfaces everywhere!
• Potentially heavy – if you look at Palermo’s project, the application core has no dependencies towards frameworks, even NHibernate, a cousin of Java’s Hibernate. Implementing things this way in Java would not be so easy unless you want to jump into XML files (yay!)