domain-driven-design

Identify bounded contexts by finding linguistic boundaries where the same word carries different meanings across teams or modules. Conduct event storming or domain storytelling sessions, then map context relationships such as upstream/downstream, conformist, or anti-corruption layer.

An entity is an object defined by identity, while an aggregate is a cluster of entities and value objects sharing one transactional consistency boundary. The aggregate root enforces all invariants and is the only entry point for modifying the cluster.

Use domain events to represent meaningful state transitions that other bounded contexts or services care about. Name them in past tense, give them sufficient data schemas, and define clear publish/subscribe contracts between contexts.

Yes, bounded contexts naturally inform microservice boundaries because each context owns its model and language. Context maps document integration patterns like published language or open host services that translate directly into service contracts.

Avoid anemic domain models where entities only have getters and setters with no behavior, god aggregates spanning the entire domain, and leaking internal models across bounded context boundaries without translation layers.

DDD is not appropriate for purely technical tasks like database index tuning or simple CRUD applications without complex business logic. It requires access to domain experts and business processes; without them, any model remains provisional.