Those approaches are not “fluff” or overly complicated if the problem-space warrants them. There are of course limits.
If you want to write a script for use once or twice, worrying about coupling and cohesion is probably not worth your time. If you are building a system to last 2-5 years out, it absolutely is worthwhile.
If you have a dead simple CRUD problem with very little business rules/operations then DDD isn’t right either. But if you have a complex set of interactions, state, and policies it’s the right call. (The big red book of ddd has a great table on exactly this)
But there are problems out there that are suitable to those approaches. The devil is in the detail; unfortunately a lot of strategic design goes by the wayside to cargo-cult zeal.
But the same can be said for the other way of thinking. I’ve worked/work with engineers who think any form of abstraction is abhorrent and that they don’t need to care about quality because they’ll delete it all and start again (they’ve not tended to care about the opportunity cost of that to their employer, either). Any database interaction looks like ActiveRecord and all technology choices are immutable.
The key in all things is balance. What is simple vs overwrought is almost entirely down to what the framing of the problem is.
If you want to write a script for use once or twice, worrying about coupling and cohesion is probably not worth your time. If you are building a system to last 2-5 years out, it absolutely is worthwhile.
If you have a dead simple CRUD problem with very little business rules/operations then DDD isn’t right either. But if you have a complex set of interactions, state, and policies it’s the right call. (The big red book of ddd has a great table on exactly this)
But there are problems out there that are suitable to those approaches. The devil is in the detail; unfortunately a lot of strategic design goes by the wayside to cargo-cult zeal.
But the same can be said for the other way of thinking. I’ve worked/work with engineers who think any form of abstraction is abhorrent and that they don’t need to care about quality because they’ll delete it all and start again (they’ve not tended to care about the opportunity cost of that to their employer, either). Any database interaction looks like ActiveRecord and all technology choices are immutable.
The key in all things is balance. What is simple vs overwrought is almost entirely down to what the framing of the problem is.