Where does domain-driven design pay for itself in a large marketplace, and where is it overhead?

Where it pays

In subdomains with genuine, contested business complexity — where the rules are intricate, change often, and are the subject of disagreement between people who all believe they understand them.

For a marketplace that means pricing and fees, seller policy and eligibility, dispute and returns, and settlement. In these areas the most valuable contribution is not the tactical patterns but the ubiquitous language: establishing that a word means exactly one thing, and that the code uses the business's word for it.

Most defects in complex business logic originate in vocabulary confusion — "listing" meaning different things to different teams, "active" meaning three different states — and a shared precise language removes an entire class of them.

Bounded contexts are the other durable contribution: recognising that the same word legitimately means different things in different parts of the business, and drawing a boundary rather than forcing one model on everyone.

Where it is overhead

In subdomains that are essentially data management. Catalogue attributes, user preferences, notification settings, reference data. Applying aggregates, repositories, domain events and value objects to create-read-update-delete produces ceremony with no benefit — several layers of indirection around a database write.

In generic subdomains you should be buying rather than building — identity, email delivery, payments processing. There is no domain model worth crafting for a capability you did not want to own.

The distinction that makes it tractable

Classify subdomains before deciding technique:

• Core — where you compete. Invest heavily; this is where the modelling pays.
• Supporting — necessary, specific to you, not differentiating. Build simply.
• Generic — buy it.

Applying the full toolkit uniformly is the most common failure, and it produces the reputation the approach has for over-engineering.

The part that is almost always worth it regardless

Ubiquitous language and explicit bounded contexts, even without any tactical pattern. They are nearly free, they improve communication between engineering and the business, and they produce boundaries that survive product changes — because a boundary drawn around what something is outlives one drawn around when it happens.