Domain-Driven Design: Architecture Evolution, Bounded Contexts, and Layered Patterns

Welcome, I am a senior architect. In this article we explore how to start a new project using Domain-Driven Design (DDD), dividing and designing its architecture step by step.

1. Terminology

Various services:

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 MVC/SSM designs, then to PaaS with micro‑services, and finally to IaaS with VM/Docker/K8s for OS abstraction.

3. Bounded Context (BC)

BCs represent sub‑domains such as Order or Inventory. The same concept (e.g., product) can have different meanings in different contexts, influencing data and behavior.

BCs also dictate technical choices: synchronous calls for tightly coupled domains, asynchronous messaging for loosely coupled ones.

4. Bounded‑Context Division Rules

Consider team size to decide granularity; avoid overly fine BCs that increase deployment overhead. After determining granularity, split by semantic relevance, business‑oriented functionality, and non‑business functionality.

5. Does a BC equal a micro‑service?

A micro‑service is a deployable unit with its own technology stack, autonomy, and scaling capabilities. One BC can map to a micro‑service, but multiple BCs may be combined if they share high cohesion.

6. Four‑Layer DDD Boundaries

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

Second boundary: Physical isolation of bounded contexts.

Third boundary: Layered architecture inside each BC – interface, domain, application, infrastructure.

Fourth boundary: Aggregates as the smallest unit of domain consistency.

7. Clean Layered Architecture

Separate interfaces from implementations, keep the domain layer independent of infrastructure, and expose services via well‑defined ports.

8. Hexagonal Architecture

Distinguish active adapters (UI, CLI) from passive adapters (databases, external services), forming a polygon of ports and adapters that isolates the core application.

9. Onion Architecture

Build on hexagonal architecture by further separating application services, domain services, and domain model layers, enforcing inward‑facing dependencies.

10. Summary

Domain‑Driven Design is a popular architectural approach; by following its four‑layer boundaries you can achieve clear domain separation, facilitate vertical business expansion, and support horizontal feature scaling.