Onion vs. N-Layered Architecture

Question

One thing beforehand: I arrive from an N-layered background.

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 Jeff Palermo's series of blog posts, Mark Seemann's contribution from a DI-perspective, "Onion-izing your achitecture", and "The clean architecture".

What all of these articles have in common is that they claim the following points:

• Focus is kept around the domain model of the business use case
• Looser coupling between layers by emphasizing the Dependency Inversion Principle
• Increased independence of external infrastructures such as frameworks, data persistence, UI
• Better testability / maintainability

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?

• Each layer just knows the abstractions of the layer below
• The concrete implementations can be kept internal to each layer and hence are in the same place as the abstractions
• The implementation details can be easily swapped out since they are internal to the layer and should not affect the rest of the application

Please help me understand the true advantages of a domain-centric architecture.

Thanks in advance!

Answer 1

Adding facades are really the first step in building an onion architecture out of an n-layered architecture. So, yes, you can get many of the benefits right away.

Testing is still problematic as you need to invert the dependency control. Controlling what has the facade is pointing to needs to move to the consumer, not the provider. This allows that consumer to swap things out for testing, or to change implementations without the provider having to know about it.