Breaking

Saturday, July 11, 2020

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!)

No comments:

Post a Comment