Domain-Driven Design

Domain-Driven Design, or DDD, is an approach to software architecture that puts the business domain — not the database or the framework — at the center of the model. Introduced by Eric Evans in 2003, it insists that engineers and domain experts build a shared, precise vocabulary and let that language shape the code. The result is software whose structure mirrors how the business actually works.

• Ubiquitous language - A single, agreed vocabulary shared by developers and domain experts, used consistently in conversation and in code.
• Bounded contexts - Explicit boundaries within which a model holds, keeping large systems from collapsing into one tangled model.
• Aggregates and entities - Domain objects with clear identity and consistency rules that own their invariants.
• Strategic design - Context maps and integration patterns that describe how bounded contexts relate and communicate.

In API practice, bounded contexts map cleanly onto service and API boundaries — each context becomes a well-scoped API with its own model and language, which is exactly what keeps a microservices estate coherent instead of chaotic. DDD gives teams a principled way to decide where one OpenAPI contract ends and the next begins, and it increasingly informs how organizations expose domain capabilities to agents, so that the vocabulary a model reasons over matches the real business it is acting on.