The Customer Illusion

The pull toward a single unified data model is strong. One User class for all contexts. One Product entity every department shares. It feels like less code, less duplication, one source of truth.

But the word "Product" means different things depending on who's asking. To billing, it's a line item with a price. To shipping, it's a physical box with a weight and a destination. Jamming both into a single class creates bloated objects full of optional fields that only matter to one context. Billing code drags around weight and dimensions it doesn't use. Shipping code carries pricing logic it doesn't need. They become hostages to each other's requirements.

The way out feels redundant: a SalesProduct in the sales context, a ShippingProduct in the shipping context. They might share an ID. That's it. But separate models for separate contexts is what creates freedom—each one can evolve independently, and changes in one don't ripple into the other.

One source of truth sounds like a virtue. But when two things only look the same, treating them as the same just moves the complexity somewhere harder to see.