domain-driven-design

Identify boundaries through linguistic signals (the same term meaning different things to different teams), organizational structure, and technical needs like consistency requirements. Draw a context map showing each context, its owning team, and the mapping patterns between them.

An entity is defined by identity that persists across attribute changes, like a bank account. A value object is defined entirely by its attributes and is immutable, like Money or Address. Prefer value objects; most domain concepts should be value objects.

Start by mapping the existing system as bounded contexts, labeling Big Balls of Mud explicitly. Build new functionality in clean contexts protected by Anti-Corruption Layers, then gradually extract functionality. A bounded context is a model boundary, not necessarily a microservice.

Use an Anti-Corruption Layer whenever integrating with a system whose model does not fit yours, such as legacy systems or third-party APIs. It translates external models into your domain language at the boundary, preventing foreign concepts from polluting your core domain.

Large aggregates create transaction contention because any change locks the entire cluster, causing conflicts when users edit different parts. Keep aggregates small with one root and minimal children, reference other aggregates by ID, and use domain events for eventual consistency.

No. A bounded context is a linguistic and model boundary, not a deployment unit. It may contain multiple services or exist as a module within a monolith. Treating them as equivalent leads to premature distribution and unnecessary operational complexity.