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

We discuss how to start a new project using Domain-Driven Design (DDD), beginning with an overview of common service models (IaaS, PaaS, SaaS) and their relevance to architectural decisions.

1. Professional Terms

IAAS: Infrastructure-as-a-Service PAAS: Platform-as-a-Service SAAS: Software-as-a-Service

2. Architecture Evolution

The diagram shows the progression from a monolithic application (SAAS) to layered MVC/SSM designs, then to microservices (PAAS) and finally to containerized, OS‑agnostic deployments (IAAS) using VM, Docker, and Kubernetes.

3. Bounded Contexts

Bounded contexts (BC) separate domains such as Order and Inventory, each with its own model and business rules. The relationship between BCs determines whether they share a microservice or communicate via synchronous calls or asynchronous messaging.

4. Four DDD Boundaries

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

Second boundary: isolate bounded contexts as process boundaries.

Third boundary: split each bounded context into interface, domain, application, and infrastructure layers.

Fourth boundary: use aggregates to keep domain models consistent.

5. Clean Layered Architecture

The clean architecture separates interfaces from implementations, keeping the domain layer independent of infrastructure and allowing easy replacement of external services.

6. Hexagonal Architecture

Adapters (driven and driving) connect the application core to UI, command‑line, databases, and external services, ensuring the core depends only on abstractions.

7. Onion Architecture

Onion architecture refines hexagonal architecture by adding distinct application, domain, and model layers, emphasizing dependency direction toward the core and keeping the outer layers replaceable.

8. Summary

Domain‑Driven Design, when applied through its four boundaries and supported by clean, hexagonal, or onion architectures, provides a solid foundation for decoupling domains, scaling vertically and horizontally, and maintaining a clear separation between business logic and technical concerns.