Bounded contexts

In DDD, a bounded context owns a consistent ubiquitous language, model, and rules. Candidate microservice boundaries appear where language, invariants, and ownership differ enough that joint evolution hurts more than integration cost.

Not every bounded context becomes a service — start with modular monolith modules and extract when autonomy or scale demands it.

On interviews: map terms that mean different things in billing versus catalog; explain anti-corruption layers between contexts.

Common pitfalls: one service per entity (OrderService, CustomerService); shared "enterprise" model across contexts; boundaries drawn from org chart alone.

Checklist:

• List terms and rules that differ between contexts.
• Assign one owning team per context.
• Use ACLs or translated DTOs at integration points.
• Extract services when release or scale pressure justifies it.