Domain-Driven Design and Architectural Patterns: From DDD to Clean, Hexagonal, and Onion Architecture

Introduction

We often hear about DDD and understand its basics, but how do we divide and design a new project from scratch following DDD principles?

1. Terminology

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 SaaS applications to layered architectures, then to PaaS with micro‑services, and finally to IaaS with containers and orchestration.

SAAS : Initially a single monolithic app, later split using MVC, SSM, and layered approaches to decouple business logic.

PAAS : As business grows, we extract common technologies (mesh, SOA, micro‑services) to build subsystems efficiently.

IAAS : High‑concurrency services require multiple servers; virtualization, Docker, and Kubernetes abstract away OS differences.

3. Bounded Contexts

Bounded Context (BC) defines a domain or module; the same concept (e.g., product) can have different meanings in order and inventory contexts.

BCs guide technical decisions: synchronous calls for order‑to‑inventory, asynchronous messaging for other interactions.

Rules for dividing BCs consider team size, granularity, semantic and functional cohesion.

One BC does not necessarily equal one micro‑service; multiple BCs can be combined or a single BC can be split into several services for performance.

4. The Four DDD Boundaries

1️⃣ Vision & Goal: Define problem space, core, generic, and supporting sub‑domains. 2️⃣ Solution Space: Bounded Context as a process isolation boundary. 3️⃣ Layered Architecture inside each BC: Interface, Domain, Application, Infrastructure. 4️⃣ Domain Layer: Use aggregates to maintain model integrity.

5. Clean Layered Architecture

Separate implementation from interfaces so the domain layer remains independent of technical details, enabling easy swapping of infrastructure components.

6. Hexagonal Architecture

Active adapters (UI, CLI) and passive adapters (databases, external services) connect to the core via ports, ensuring the core depends only on abstractions.

7. Onion Architecture

Extends hexagonal by adding application services, domain services, and domain model layers, emphasizing inward‑facing dependencies and testability.

8. Summary

Domain‑Driven Design, combined with the four DDD boundaries, provides a solid foundation for decoupling domains, supporting vertical and horizontal scaling, and guiding the choice of architectural styles such as clean, hexagonal, and onion architectures.