Note: BLL = Business Logic Layer (can also mean your domain)

I'm trying to understand the onion architecture. It seems to me that it's actually the same thing as the layered architecture, only with the dependency inversion principle (DIP) applied. For example, this is the typical layered architecture (arrows represent dependencies):


Note: That's simplified, and should not imply that DIP can't/isn't used with it. DIP simply means that we should depend on abstractions.

This is the typical onion flow (also simplified):


Notice the last arrow is reversed. The BLL has the abstractions, so they're at the center of the onion, and the other layers reference it. Onion article: http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

Since I'm used to the layered architecture, I wanted to see what the flow would look like if I combined that with DIP. Here it is:

UI > [interface] < BLL > [interface] < DAL

Excellent diagram of DIP, which mirrors this. https://en.wikipedia.org/wiki/Dependency_inversion_principle

Here is an article explaining the difference between layered and onion. It made me have the questions I presented above. http://blog.ploeh.dk/2013/12/03/layers-onions-ports-adapters-its-all-the-same/

So my question is, what is the difference between the onion architecture, and the layered architecture with DIP? Is there one?

My question has been flagged as a possible duplicate of this one: Onion architecture vs 3 layered architecture Mine is different because I want to know if there really is such a thing as the onion architecture. If you claim the onion architecture is layered + DIP, then does the onion really exist? Or would that mean that the onion really is just a version of layered, like layered with bad practices?

  • 1
    Possible duplicate of Onion architecture vs 3 layered architecture
    – gnat
    Commented Feb 15, 2018 at 14:32
  • 1
    Words mean what people think they mean. If people use 'onion architecture' to mean something specific that exists, then the 'onion architecture' exists. I think what you are really asking is whether it is synonymous to the Layered Architecture w/ DIP.
    – JimmyJames
    Commented Feb 15, 2018 at 14:38
  • 2
    consider giving a read to guidance here: On discussions and why they don't make good questions
    – gnat
    Commented Feb 15, 2018 at 14:47
  • 1
    @JimmyJames Yes, that's what I'm asking. And if it's true, then I wish articles that explain the onion architecture would state that right up front. Instead there are these long explanations, and diagrams, that explain the onion architecture as if it's some radical new concept.
    – Bob Horn
    Commented Feb 15, 2018 at 15:05
  • 2
    I think the real question should be "What is difference between layered architecture and layered architecture with DIP?" . And to me, that difference is huge and critical to what onion architecture really is about.
    – Euphoric
    Commented Feb 15, 2018 at 15:30

1 Answer 1


It seems to me that most 'new' things in software architecture are old ideas refurbished and combined with new technologies or other ideas. Often these are incremental.

In this case, the change that I think matters is the database is no longer the center of the design. This is not an minor change; it's pretty fundamental. So is the "onion architecture" really just the layered architecture plus DIP? Maybe. But steel is roughly iron plus carbon. Does that mean steel isn't a real thing?

Words are labels. This one stuck. I'm not sure what else there is to say about it.

  • 1
    "the database is no longer the center of the design." That implies that it was in the layered architecture. Why would that be the case? Because everything depends on it? (The arrows all point toward it.)
    – Bob Horn
    Commented Feb 15, 2018 at 15:51
  • 2
    @BobHorn, Correct. In multi-tiered architecture with the database as the bottom tier, you typically end up with leaky abstractions or a lot of business code in stored procedures. In the Onion architecture, the persistence is mapped to domain objects and all the business logic is in those domain objects. It makes the database a bolt-on, and much easier to trade it for NoSQL if that fits the architecture needed. Or more likely the case when the licensing for one database becomes too expensive it makes it easier to change for another database from another vendor. Commented Feb 15, 2018 at 15:56
  • 3
    @BerinLoritsch: It doesn't have to be that way. You can have a layered architecture and simply avoid stored procedures. And decoupling the database from an architecture is an unremarkable technique; if that's all there is to onion architecture it's not particularly interesting. Commented Feb 15, 2018 at 16:16
  • 1
    @RobertHarvey I'm not sure I would call it 'remarkable' but the onion architecture forbids using the database (or any other storage infrastructure) directly. I've seen a lot of layered architectures where some people would go through the service layer but other teams might go directly to the database. As I understand it, if you say "onion architecture" you are specifically saying that it not an option.
    – JimmyJames
    Commented Feb 15, 2018 at 16:26
  • 1
    "If I have seen so far it is only because I have stood on the shoulders of giants" Isaac Newton. There are few things that aren't really some other thing, just with something else added or removed. What the op is really complaining about is the hype used to get us to listen to the lesson. If you come away saying "I knew that already" then great. But not everyone knew that. I'm happy if we can keep down the number of names for identical things. Layered is not the same as onion but ports & adapters as well as clean architecture sure seem the same to me. Commented Feb 15, 2018 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.