[rtpg]

My experience has been that shops that avoid abstraction (namely, lacking a strong separation between controller code and business logic) end up suffering a decent amount long-term.

There's an argument that many layers of abstraction lead to too much boilerplate, but lacking abstractions can cause slowdown long-term because it gets harder and harder to handle all the interactions between subsystems.

You can always automate boilerplate "generation". You can't automate inconsistent business logic.

[saltedmd5]

The problem is the idea that "layers" and "abstraction" come as a package. You don't need layers to create meaningful and useful abstraction - in fact more often than not they prohibit it.

And you certainly don't need layering within a single codebase - if I see one more codebase where everything is a FooController, FooService or FooRepository I just might go insane.

People abstract logic away from controllers only to dump it all into a massive procedural "service" class, which leads to no end of pain down the road. Once you stop seeing layers and start seeing a vertical dependency tree starting at the controller, the world gets a lot more rosy. Consumer-driven development helps here.

[bryanrasmussen]

layers of abstraction may help agencies that move between different projects for different companies in first of all being able to reuse what they have done between their customers, but also in building something that someone else will find difficult to maintain - thereby providing lock-in.

[youthclub]

Interesting, this is how most of our code ends up . But the service abstraction has been beneficial for our other applications which consume them too. I’m going to read closely about Comsumer driven approach though.