Applying Domain-Driven Design: Architectural Evolution, Bounded Contexts, and Clean Architecture

Preface

We have heard of DDD and now explore how to divide and design a new project from scratch following DDD principles.

1. Professional Terminology

IAAS: Infrastructure‑as‑a‑Service

PAAS: Platform‑as‑a‑Service

SAAS: Software‑as‑a‑Service

2. Architectural Evolution

The diagram shows the evolution from a monolithic application (SAAS) to layered MVC/SSM, then to a platform approach (PAAS) with shared technologies such as mesh, SOA, micro‑services, and finally to infrastructure abstraction (IAAS) using VM, Docker, and Kubernetes.

3. Bounded Context

A bounded context (BC) defines the meaning of domain concepts within a specific sub‑domain; for example, the concept of “product” differs between the order and inventory contexts.

Technical interaction between BCs often requires message middleware for asynchronous communication.

Guidelines for dividing BCs consider team size, semantic relevance, and functional cohesion.

One BC does not necessarily map one‑to‑one to a microservice; multiple closely related BCs may share a service, while a high‑traffic BC may be isolated as its own microservice.

4. The Four‑Layer DDD Boundary

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

Second boundary: limit the solution space with bounded contexts as process isolation.

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

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

5. Clean Layered Architecture

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

6. Hexagonal Architecture

Distinguish between active adapters (UI, CLI) and passive adapters (databases, external services); each side is an interface with its own implementation, forming a polygon‑shaped architecture.

7. Onion Architecture

Extends the hexagonal model by further separating application services, domain services, and domain models into concentric layers, keeping inner layers free of external dependencies.

Conclusion

Domain‑Driven Design, when applied through its four‑boundary framework, provides clear separation of concerns, facilitates vertical and horizontal scaling, and lays a solid foundation for future business expansion.