Posted by ingve 5 hours ago
If you say, “we have CRUD apps and some event-driven, truly bespoke stuff,” you have the problem of devs not wanting to work on the CRUD apps and only wanting the bespoke stuff.
Things I have tried
1. Hire seniors who are jaded by overengineering; they are happier to work on CRUD apps and will do things well.
This is my favorite strategy but there are not as many of these people.
2. Have contractors do CRUD and full-time employees work on core features.
This can create an uncomfortable culture split and if you’re not confident in managing contractors, can mean delays or having the customer-facing stuff look sloppy. I’ve also found some contract shops are not set up well to do security-critical things that aren’t a differentiator, like auth.
3. Pay for non-core stuff through vendors, and have employees focus on core things and a smaller set of non-differentiators.
This requires higher vendor spend but is probably the easiest to have a consistent culture and hiring setup.
I am a DDD noob (currently reading the book Domain Modeling Made Functional), but maybe someone can elaborate on how one's supposed to make such decisions when there's plenty of uncertainty.
This factory-service-repository word salad sounds like a parallel fantasy based on preconceptions of a certain cohort of self-reinforcing “believers”. Fuzzy words get abused the most. And the more middle management, the faster the meaning gets drained from them. I guess DDD took off mostly in MS/Enterprise environments, which would explain the butchering.