[cangeroo]

The article is extremely short and by an unknown author, so there isn't much to discuss.

But I've met many people who hated onion architecture with a passion.

I have a few theories:

- Maybe a lot of programmers have ADHD, are autistic, or suffer from dyslexia, and find planning, naming, designing abstractions as excruciating activities.

- Onion architecture etc. is a long-term strategy that mainly benefits the company/project owner, but not the individual contributor. So it basically has to be forced upon programmers, who will resist it in every way possible, because they have no real incentive to use it.

- It's supposed to make writing software easier. But it really requires an IDE that's designed for abstractions, such as IntelliJ, and also requires a different way of working with the code. It's also verbose. So it's really a different paradigm, and it won't work if you use a plain text editor. You'll drown in code and a vast number of files.

- Onion architecture is not OOP, but often mixed in with enterprise OOP, and therefore bad associations that come with enterprise OOP.

Any other thoughts on why people resist it so much?

And what changes in how we work with code, would make onion architecture more practical?

[djeastm]

>- Maybe a lot of programmers have ADHD, are autistic, or suffer from dyslexia, and find planning, naming, designing abstractions as excruciating activities.

I don't know about the medical conditions, per se, but I think this does bring up a point that is often overlooked when discussing best practices: our brains are different and organize things in different ways.

What works and makes sense to one group of people might not work or make sense to another group of people. I find that more literal-minded people are frustrated by what they see as unnecessary abstraction and are fine with duplicated code whereas people who think in abstractions have no problem seeing the bigger picture and are proponents of abstractions when the abstractions make sense to them.

I have coworkers who will look at a codebase with a layered/onion architecture and immediately understand and reuse all of the abstractions without issue and others who will immediately want to simplify it and change it all into concrete implementations. I find myself to be fairly evenly split so I see it from both sides.

I think it's often more about the nature of the latest person who looks at the codebase than the codebase itself. Eye of the beholder and all that.

[mech422]

>>does bring up a point that is often overlooked when discussing best practices: our brains are different and organize things in different ways.

I really notice this when I first look at a code base...Its not that the code is 'bad' but more of a 'what were they thinking' when the code was laid out. Eventually you get used to it, but its a bit of a shock when you first encounter it as the organization, data structures, etc are so 'alien' to how you would organize it yourself...

[chipdart]

> What works and makes sense to one group of people might not work or make sense to another group of people. I find that more literal-minded people are frustrated by what they see as unnecessary abstraction and are fine with duplicated code whereas people who think in abstractions have no problem seeing the bigger picture and are proponents of abstractions when the abstractions make sense to them.

I don't agree. I don't think this is an issue of having different points of view. It is an issue of being oblivious to constraints that result in this specific configuration.

If they do not understand the problem, they don't understand the solution either.

No one adds abstractions and interfaces because they like complexity. In layered architectures, interfaces and abstraction layers are used extensively to manage dependency relationships.

Take for example dependency inversion. Dependency inversion is used extensively to ensure that inner layers, the modules which should change less frequently, do not depend on implementation details implemented by outer layers. Your inner layers need to get data from other services, save data in a data store, etc. But you should not need to change your inner layers just because you need to call a service. Consequently, you eliminate these dependencies on external services by having your inner layers provide the necessary and sufficient interfaces they require to handle external data, and then have the external services implement these interfaces provided by internal services. This can be interpreted as an unnecessary layer of abstraction if you do not have a clue about what's happening. I mean, your inner layers could simply call a database, but instead they have an interface that's implemented God knows where, and then you need to hunt down how it's used. Except this abstraction layer is of critical importance.

[cangeroo]

Have you found anything that makes everyone happy and productive?

I sometimes wonder if we'll replace traditional design patterns, especially OOP, with new patterns, that are neither OOP or FP, but perhaps a different paradigm (e.g. how Prolog is wildly different from C++).

[djeastm]

>Have you found anything that makes everyone happy and productive?

Not really. It's kind of a constant push-pull and a lot of compromises. In the end it's just about getting things done and dealing with the friction in stride when it comes.

I've often wondered what it would be like working at a workplace where everyone programs with the same mental models, but have never worked at such a place myself and I'm not even sure it's possible.

[victorNicollet]

> Onion architecture etc. is a long-term strategy that mainly benefits the company/project owner, but not the individual contributor. So it basically has to be forced upon programmers, who will resist it in every way possible, because they have no real incentive to use it.

Although I was aware of it for a while now, I had never seen this misalignment (between what I called ease-of-writing and ease-of-maintenance) stated so clearly in so few words. Thank you !