Layered Architecture with DI vs onion architecture?

Question

Could anyone please explain the difference between onion architecture and Layered architecture using dependency inversion? They look exaclty the same to me. Any input is greatly appreciated :)

Louth

You might find this Mark Seemann's article interesting. – Cathedral

Answer 1

I've always thought of it exactly that way: N-tier architecture meets DI--with a couple of constraints.

The most important thing is that code in inner layers is not coupled to code in outer layers (controlled direction of coupling). I also constrain myself layers can only communicate with the layer immediately beneath them (controlled depth of coupling). To my knowledge, no one else is advocating that particular constraint, and Palermo specifically rejects it.

Mercedes

Thank you for taking the time to respond to my question. So essentially, When you opt for DI and using interfaces to decouple depedendencies, you are transforming your architecture to Onion architecture( from N Layered ). Let me know if this statement is incorrect. – Louth

Also, are application services( AKA service layer pattern ) considered part of the core? or is something that is usually placed in a different project/module from the core? – Louth

What I always say is that the question which layers you have and what their respective responsibilities they have is optional. Palermo is a DDD guy and I'm not so his implementation would be quite different from mine. As a general rule the interfaces and any contracts they expose are part of your onion layers. The implementations of those interfaces is considered to be infrastructure. – Mercedes

For my money your first statement is correct as long as you are observing the direction (and in my case the depth) of your dependencies. Others may have a more contoured opinion, but I think you're essentially right. – Mercedes