I generally find that abstraction is good, but layering is bad. Let's say I have components A, B, and C that all do something useful and are good abstractions, the difference between good code and bade code is how they interact. In bad code A will call B and B will call C, from the top level it's completely opaque how everything fits together. I'd much rather A returns something and let's the caller pass it to B. There is very little difference in code required but it makes a world of difference to making it comprehensible.

IMO the most important thing when introducing a layer of abstraction is the name of the new component. I sometimes spend 2 or more minutes making up a name that best describes what this layer is about.

ProTip: Manager or Controller is not a good name. To me a good name is eg „PostDetailSerializerResolver“ - it’s a component that will resolve serializers for post detail objects. And according to concept of single responsibility, it should only do that. If you need it to do more, you must change the name.

> I sometimes spend 2 or more minutes making up a name that best describes what this layer is about.

Some of the best refactoring I ever did for long-term code-maintenance was nothing more than untangling a web of abstraction layers and renaming them to fit the actual context, changing nothing to the functionality of the code.

Sometimes you start out with an idea for what the architecture will be, but then things change and the naming isn't updated.

We tend to speak of abstractions in only positive terms. Some negative ones could include opaque, obtuse, disjointed, etc.

When I think of abstractions I think abstraction == API and good API design is very hard.