Understanding Domain-Driven Design: Boundaries, Contexts, and Architectural Patterns

Preface

We have all heard of DDD and understand its basics; this article shows how to start a new project and structure it according to DDD principles.

1. Terminology

Various services:

IAAS: Infrastructure-as-a-Service

PAAS: Platform-as-a-Service

SAAS: Software-as-a-Service

2. Architectural Evolution

The diagram illustrates the evolution from monolithic applications to layered, service-oriented, and finally infrastructure‑oriented architectures:

SAAS: early monoliths, later split using MVC, SSM, layers to decouple business.

PAAS: extracting subsystems with shared technologies like mesh, SOA, micro‑services.

IAAS: scaling out with multiple servers, using VM, Docker, K8s to abstract OS differences.

3. Bounded Context

BC and business relationship: A domain such as Order may be a sub‑domain; the same entity (e.g., Product) can have different meanings in different contexts (price in Order, stock in Inventory).

BC and technology relationship: Interaction between sub‑domains may require synchronous calls (e.g., Order → Inventory) or asynchronous messaging, prompting the use of message brokers.

Bounded‑context division rules consider team size, semantic and functional cohesion, and aim to avoid overly fine granularity that burdens deployment.

Does one BC equal one microservice?

Microservices are independently deployable units with their own technology stack; a BC can map to a microservice when traffic or cohesion justifies it.

4. The Four DDD Boundaries

The four layers guide architecture design:

First boundary: define vision, core, generic, and supporting sub‑domains.

Second boundary: bounded contexts act as process isolation.

Third boundary: within each context, separate interface, domain, application, and infrastructure layers.

Fourth boundary: aggregates enforce consistency inside the domain layer.

5. Clean Layered Architecture

The diagram shows that the domain layer is kept independent of infrastructure, allowing easy swapping of technical implementations while exposing services to external callers.

6. Hexagonal Architecture

Active adapters: UI, CLI, etc., where controllers act as entry points inside the application.

Passive adapters: external services, storage, each represented as ports with concrete implementations outside the core.

Key characteristics:

Dependencies point inward; interfaces are used to decouple.

Improved testability.

7. Onion Architecture

The onion model extends the hexagonal approach by further separating application services, domain services, and domain models within the inner layers.

Features:

Build applications around an independent domain model.

Define interfaces in inner layers, implement them outward.

Dependencies always point toward the center.

Application code can run without infrastructure dependencies.

Summary

Domain‑Driven Design is a popular architectural approach; by following its four boundaries you can effectively decouple domains, support vertical and horizontal scaling, and lay a solid foundation for future growth.