Mastering Domain-Driven Design: From Concepts to Clean Architecture

Preface

We often hear about DDD, but how can we structure and design a brand‑new project from scratch using the DDD process?

1. Terminology

IAAS: Infrastructure‑as‑a‑Service

PAAS: Platform‑as‑a‑Service

SAAS: Software‑as‑a‑Service

2. Architectural Evolution

The diagram illustrates the evolution through three layers:

SAAS : Early monolithic applications where business logic is tangled; later separated using MVC, SSM, and layered approaches.

PAAS : As business grows, subsystems are extracted; common technologies like mesh, SOA, and micro‑services are reused to speed up development.

IAAS : High‑concurrency services (e.g., order service) require multiple servers across different OSes, leading to virtualization, Docker, and Kubernetes for OS abstraction.

3. Bounded Context

Bounded Context (BC) defines the relationship between business domains and technical solutions.

Business example: In an order system, the "product" concept differs from that in inventory—price vs. stock quantity.

Technical example: Aggregating multiple sub‑domains at the application layer may require synchronous calls (order‑to‑payment) or asynchronous messaging (order‑to‑inventory).

BC division rules consider team size, semantic relevance, and functional relevance to avoid overly fine granularity that burdens deployment and operations.

One BC does not necessarily equal one microservice; a BC can span multiple services or be combined with others based on traffic and cohesion.

4. Four‑Layer DDD Boundaries

First boundary: Define vision, goals, problem space, core, generic, and supporting sub‑domains.

Second boundary: Bounded Contexts act as physical isolation between processes.

Third boundary: Within each BC, separate interface, domain, application, and infrastructure layers.

Fourth boundary: Use aggregates in the domain layer to ensure model consistency.

5. Clean Layered Architecture

By separating implementation from interfaces, the domain layer remains independent of technical details, allowing easy replacement of infrastructure components and exposing services to external callers.

6. Hexagonal Architecture

Passive adapters handle external resources such as databases and third‑party services, while active adapters deal with user‑facing inputs like UI or CLI. The architecture consists of multiple ports and adapters forming a polygon shape.

Key characteristics:

Dependencies point inward, promoting interface‑driven design.

Improved testability.

7. Onion Architecture

Extends the hexagonal model by further separating the inner business logic into application services, domain services, and domain models.

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 be compiled and run without the infrastructure layer.

Conclusion

Domain‑Driven Design is a popular architectural approach; following its four‑boundary model enables effective decoupling of domains and provides a solid foundation for vertical and horizontal scaling of business capabilities.