In the past, I’ve really wanted better strategies for making this work organizationally.
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 sympathize with the “rant”. In the book I read about DDD it was very clear you should work side by side with the domain expert (client usually) to the point of agreeing on the same terminology (nouns & verbs mostly). In order to have a shared mental model, of the business. This is helpful for both parties.
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.
I really like the idea of bounded contexts and aggregates in theory. What I still don't understand is how defining them can be feasible at the beginning of a project when you have too many unknowns (some of which are unknown unknowns).
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.
In the past, I’ve really wanted better strategies for making this work organizationally.
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 sympathize with the “rant”. In the book I read about DDD it was very clear you should work side by side with the domain expert (client usually) to the point of agreeing on the same terminology (nouns & verbs mostly). In order to have a shared mental model, of the business. This is helpful for both parties.
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.
I really like the idea of bounded contexts and aggregates in theory. What I still don't understand is how defining them can be feasible at the beginning of a project when you have too many unknowns (some of which are unknown unknowns).
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.