Sales wants a `leadScore` field on `Customer` and Billing wants a `taxId` field, and someone proposes one `customers` service with one table holding both. What's the argument against, and what would you build instead?

Sales' customer and Billing's customer are two different concepts that happen to share a name: a prospect in a pipeline versus an account that owes money, changing for different reasons under different teams. One table holding both means every field the other side doesn't use is nullable, every business rule is conditional on which "kind" of customer a row is, and the two teams block on each other's migrations even though they rarely touch the same fields. The fix is two models — a bounded context each — sharing only an identity (customerId) and the genuine overlap (name, email), with one side owning the shared fields and the other copying them from its events.