Do i hear the question correctly? It’s in a nutshell another way of asking why don’t developers do better job by following practice X.
Because a) incentives b) rarely a complex enough product/company fits some fancy “practice X”.
A) you usually don’t get promoted by simply better organizing a process or your team work. But rather for pushing something tangible as quickly as possible out the door.
B) i already have common understanding of the product with designers after some initial onboarding period - why do i have to bother loading yet another set of concepts and constraints in my head already full of tickets, docs, meetings, obligations, decisions, code reviews, proposals, incidents, weird bugs, slack bots, performance reviews, open discussions, pairing sessions, important emails, failing tests, dissapointed customers, deadlines, bad codebase to refactor, juniors to mentor, slides to prepare, HN posts to comment?
:)
I'm not calling out engineer's—not my intention. Incentives not matching is real, cognitive overload is real. But I see domain modeling as a collaboration tool, not as an extra step or critique. I feel it's a common language and a steady foundation for all product partners to work from.