[Quothling]

It was 10-20 years ago. Today nobody competent does it because it doesn't scale. A lot of the good parts of onion layering still exists in more modern architectures, especially in languages which are still very tied to the original OOP academic principles like Java or C# where you're likely to see interfaces for every class implementation, but as time has moved forward it's not really necessary to organize your functions inside classes, even if you're still doing heavy OOP. So today you're more likely to see the good parts of the onion layering build into how you might do domain based architecture. So even if you're doing models, services and so on, you build them related to a specific business domain where they live fully isolated from any other domain. Which goes against things like DRY, but if you've ever worked on something that actually needed to scale, or something which lived for a long time, you'll know that the only real principle that you have to care about is YAGNI and that you should never, ever build abstractions until you actually need them.

Part of the reason onion still exists is because academia is still teaching what they did almost 30 years ago, because a lot of engineers were taught 30 years ago and because a lot of code bases are simply old. The primary issue with onion layering is that it just doesn't scale. Both in terms of actual compute but also in terms of maintenance. That being said, a lot of the ideas and principles in onion layering are excellent and as I mentioned still in use even in more modern architectures. You'll likely even see parts of onion layering in things like micro-services, and I guess you could even argue that some micro-service architectures are a modern form of onion layering.

The more competent a system is designed, however, is often shown in how few abstractions are present. Not because abstractions are an inherent evil, but because any complexity you add is something you'll have to pay for later. Not when you create it, not a year later, but in five years when 20 different people have touched the same lines of code a hundred times you're very likely going to be up to your neck in technical debt. Which is why you really shouldn't try to be clever until you absolutely need to.

[usrbinbash]

> you should never, ever build abstractions until you actually need them.

This should be put on the cover of every programming textbook, in very bold, very red, letters.

Right next to: "Measure before you optimize" and "Code is read 1000x more often than it is written"