A marketplace is deciding whether "listing" and "inventory" are one domain or two. How should the boundary be decided, and what evidence settles it?

How the boundary should be decided

By language and by who decides. Two heuristics, and they usually agree.

1. Does the same word mean the same thing? If "listing" means something different to the seller-tools team than to the search team than to the fulfilment team, those are different bounded contexts and forcing one model on them produces a shared model that serves none of them well.

2. Who decides when it changes, and for what reason? If listing content changes because sellers want richer descriptions, and inventory changes because fulfilment introduces multi-warehouse allocation, they change for different reasons on different authority. That is two domains.

The evidence that settles it

• Change history. Do changes to one routinely require changes to the other? Persistent co-change is evidence of one domain badly split. Independent change over a year is evidence of two.
• Conversation. Do the same people discuss both, in the same meeting, using the same terms? Language boundaries in an organisation are usually real boundaries.
• Transactional need. Must a change to both be atomic? A genuine invariant spanning the two is a strong argument for one domain, because splitting it means a saga where a transaction would do.
• Different lifecycles. A listing exists before, during and after inventory is available; inventory exists independently of any listing in a multi-channel seller's world. Different lifecycles suggest different domains.

For this specific case

They are usually two domains with a relationship, because a listing is a presentation and commercial offer while inventory is physical availability. A seller can have inventory with no listing, a listing can exist across several fulfilment sources, and the two change for entirely different reasons.

But the answer depends on the business: for a marketplace of unique second-hand items, listing and inventory are nearly the same thing — every item is a singleton — and splitting them creates a distributed transaction where a single row would do.

That is the real lesson: the boundary is a property of the business model, not of the words.

The cost of getting it wrong in each direction

Split too finely: a saga where a transaction would suffice, eventual consistency in a place that needs an invariant, and a chatty interface for what should be one operation.

Merged when they should be separate: a shared model serving neither well, teams blocked on each other's changes, and a single deployment for two independent change cadences.

Of the two, merging wrongly is easier to fix — splitting a module is more tractable than merging two services and their data — which argues for erring toward fewer boundaries when the evidence is ambiguous.