I'm a product designer with a front-end background (Rails, Swift) trying to deepen my understanding of domain modeling.
I see domain models as a shared foundation between product, design and dev. But I don't see it happening on teams, ever. It helps me understand what's possible, anchors feature flows in what's possible, avoids over designing.
So why aren't more product teams collaborating on ERDs? Sometimes when I ask for a schema or ERD to get oriented, I get blank stares. Are there different ways developers think about data modeling beyond ERDs?
Is collaborating on the domain model a good entry point between design and engineering? What does that collaboration usually look like in your org?
Would love to hear how others approach this, especially from engineers who work closely with designers, or designers who’ve gotten better at it over time.
dgunay2 days ago
My (limited) experience with this is that product owners will prefer to just let engineers figure out the best data model for what they're asking. This may come from either an awareness that they can't competently collaborate on this, an ignorance of that even being an option, or a desire to not be overly prescriptive of a particular solution.
aristofun2 days ago
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?
:)
adangitop2 days ago
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.
thuanaoa day ago
Most people have no idea what domain modeling is, what ERD is, why it's useful, etc.