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.

Answer 2

I'm sharing the same opinion as yours, We're planning to kick off a new project and one of my coworkers suggested the onion architecture, but after documenting a bit about it I was a little bit confused, because (for me!) the fact that each client layer must depend only on the abstraction of the used layer is a matter of best practice that must always be in mind whatever architecture we're planning to use, DI is a "Principle" not an architecture so I couldn't realize how just using the N-Layered architecture with "good OO Principles" make it a new architecture?

In this way we'll end by hundreds of new architectures just by combining all OO Principals and Go4 patterns to the Entreprise Application Architectures.