title: Onion vs. N-Layered Architecture
body: <p>One thing beforehand: I arrive from an N-layered background.</p>
  
  <p>I have now spent quite a bit time getting my head around Onion Architecture and related Domain Driven concepts such as Hexagonal Architecture reading resources like <a href="http://jeffreypalermo.com/blog/the-onion-architecture-part-1/">Jeff Palermo's series of blog posts</a>, <a href="http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same/">Mark Seemann's contribution from a DI-perspective</a>, <a href="http://www.incredible-web.com/blog/the-onion-architecture/">"Onion-izing your achitecture"</a>,  and <a href="http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html">"The clean architecture"</a>.</p>
  
  <p>What all of these articles have in common is that they claim the following points:</p>
  
  <ul>
  <li>Focus is kept around the domain model of the business use case</li>
  <li>Looser coupling between layers by emphasizing the Dependency Inversion Principle</li>
  <li>Increased independence of external infrastructures such as frameworks, data persistence, UI</li>
  <li>Better testability / maintainability</li>
  </ul>
  
  <p>Well, that all sounds incredibly nice and those diagrams look sweet as well. But the question that arises for me: Isn't all of that achieved by merely adding façades to my traditional N-layered architecture? </p>
  
  <ul>
  <li>Each layer just knows the abstractions of the layer below</li>
  <li>The concrete implementations can be kept internal to each layer and hence are in the same place as the abstractions</li>
  <li>The implementation details can be easily swapped out since they are internal to the layer and should not affect the rest of the application</li>
  </ul>
  
  <p>Please help me understand the true advantages of a domain-centric architecture.</p>
  
  <p>Thanks in advance!</p>