Stop Overloading the Customer Domain in Master Data Models
In last week’s post, MDM Is Not a Tool – It’s a Practice Built on Process and Governance, we looked at why technology alone can’t solve master data challenges, and why process, governance, and culture are the real foundations of MDM success.
This week, we’re shifting from practices to design choices. One of the most common mistakes in MDM is overloading the customer domain with entities that don’t belong there. We’ll unpack why this happens, the risks it creates, and how proper domain modeling can bring clarity back to your master data.
Why “Customer” Becomes the Catch-All in MDM
In many master data management programs, the customer domain starts small, built to support billing, CRM, or order processing.
But over time, it becomes the default home for anything with a name or tax ID: partners, resellers, affiliates, vendors, leads, even internal departments.
This usually happens for convenience:
- It’s already integrated and governed
- It avoids creating another domain
- It solves an immediate business request
Short term, it feels efficient. Long term, it creates technical debt and governance headaches.
The Risks of Stuffing Every Entity into the Customer Table
Overloading the customer domain breaks more than just definitions. It weakens the entire MDM architecture.
Attribute Bloat
The table swells with fields that only apply to certain records. Terms like payment method or credit limit become optional or meaningless for most rows.
Validation Gaps
Required fields can’t be enforced consistently, forcing rules to be skipped, overridden, or watered down.
Reporting Confusion
Metrics get inflated when non-customers are counted. What looks like growth may just be noise.
Integration Complexity
Downstream systems receive records with unclear semantics, forcing brittle rules based on flags and partial data.
Business Misalignment
Ownership disputes emerge: marketing wants leads, legal needs vendor records, operations needs partners, all in one table.
Why This Is a Business Design Problem, Not Just a Technical One
Domain modeling isn’t just about schemas; it’s about business clarity.
When you define domains by purpose, lifecycle, and relationship to the organization, you gain:
- Reusability – Share addresses, contacts, and structures across domains without polluting core entities
- Clarity – Stewards and consumers know exactly what the data represents
- Flexibility – Extend one domain without breaking others
- Governability – Apply quality rules consistently and assign clear ownership
How to Tell If You’re Misusing the Customer Domain
Warning signs your customer table is overloaded:
- Flags like
IsVendor,IsPartner, orIsAffiliateare common - Entities that will never purchase from you are stored as customers
- Internal departments, government agencies, and prospects all live in the same table
- Validation rules fail because they don’t apply to every record
What to Do Instead: Model Roles and Relationships Explicitly
Good MDM architecture models the core entity once, then connects it to roles through separate objects or relationships.
Examples:
- An organization may be both a supplier and a client, each with its own lifecycle, validations, and integrations
- A person may be both a patient and a donor, each with unique privacy rules and processes
This approach preserves clean domain boundaries while supporting complex, multi-role relationships.
Questions to Ask Before Adding to the Customer Domain
- Is this entity truly a customer?
- Does it have a different primary role?
- Are we forcing it into this model because it already exists?
If the answer points to convenience over clarity, it’s time to define a new domain.
Final Thought: Domain Modeling Is a Governance Decision
When the customer domain in MDM tries to do everything, it ends up doing nothing well.
Clear, well-defined domains scale better, integrate cleaner, and earn trust faster.
Treat domain modeling as a business design decision, not just a database exercise, and stop stuffing everything into customer.
