Domain-Driven Design: Concepts, Bounded Contexts, and Architectural Patterns

We have all heard of DDD and understand its basics, but how do we start a new project by applying DDD from the ground up? This guide walks through the process of dividing and designing architecture using DDD principles.

1. Terminology

Various services:

IAAS – Infrastructure-as-a-Service

PAAS – Platform-as-a-Service

SAAS – Software-as-a-Service

2. Architecture Evolution

The diagram shows the evolution from monolithic applications (SaaS) to layered designs, then to PAAS‑style subsystems using mesh, SOA, micro‑services, and finally to IaaS‑style deployments with VMs, Docker, and Kubernetes to abstract operating systems.

3. Bounded Context

Bounded contexts (BC) define how business sub‑domains such as Order or Inventory are separated. The same concept (e.g., Product) can have different meanings in different contexts, and interactions between contexts may require synchronous calls or asynchronous messaging.

Bounded Context Division Rules

First consider team size to avoid overly fine granularity, then split based on semantic relevance, business‑oriented functional relevance, and non‑business functional relevance, resulting in multiple bounded contexts.

Does a BC equal a micro‑service?

A micro‑service is a deployable unit with its own technology stack and scaling characteristics. A BC represents a domain or module; multiple closely related BCs may share a micro‑service, or a high‑traffic BC may be isolated as its own micro‑service.

4. The Four DDD Boundaries

DDD uses four boundaries to structure the system: the first defines vision, core, generic, and supporting sub‑domains; the second isolates bounded contexts as physical process boundaries; the third splits each context into Interface, Domain, Application, and Infrastructure layers; the fourth introduces aggregates to preserve domain integrity.

5. Clean Layered Architecture

This style separates implementation from interfaces, keeping the domain layer independent of any specific technology, which facilitates swapping infrastructure components and exposing services to third‑party callers.

6. Hexagonal Architecture

Active adapters handle input from UI or CLI, while passive adapters deal with external services and storage. All inputs/outputs are treated as ports with concrete implementations, promoting isolation and testability.

7. Onion Architecture

Building on the hexagonal model, the onion architecture further separates the inner domain model into Application Services, Domain Services, and the Domain Model itself, enforcing inward‑directed dependencies and allowing the outer layers to be swapped independently.

8. Summary

Domain‑Driven Design is a popular architectural approach; by following its four‑boundary model, teams can achieve clear domain separation, facilitate vertical and horizontal scaling, and lay a solid foundation for future extensions.