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

We all have heard of DDD and understand its basics, but how do we divide and design a new project from scratch following the DDD process?

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 a monolithic SAAS application, through PAAS with service isolation, to IAAS with multiple servers and container technologies such as Docker and K8s.

3. Bounded Context (BC) Concept

BC defines the relationship between business domains and technical solutions. For example, an order system and an inventory system are separate sub‑domains, each with its own meaning for the concept of “product”.

Technical solutions such as message middleware are needed when sub‑domains must interact, e.g., synchronous calls for order‑to‑payment and asynchronous notifications for inventory updates.

4. Bounded‑Context Division Rules

First consider team size to decide granularity; too fine‑grained BCs overload deployment and operations. Then split by semantic and functional relevance, both business‑oriented and non‑business‑oriented.

5. Is a BC a Microservice?

A microservice is an independently deployable unit with its own technology stack. A BC can correspond to a microservice when the domain has high traffic or strong cohesion.

6. Four‑Layer DDD Boundaries

1️⃣ Define vision, goals, and core sub‑domains. 2️⃣ The bounded context forms a physical process isolation layer. 3️⃣ Inside each BC, separate interface, domain, application, and infrastructure layers. 4️⃣ Use aggregates in the domain layer to maintain consistency.

7. Clean Layered Architecture

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

8. Hexagonal Architecture

Adapters (ports) handle input (UI, CLI) and output (databases, external services). The core depends only on abstractions, improving testability and isolation.

9. Onion Architecture

Extends hexagonal architecture by adding application service, domain service, and domain model layers, enforcing dependency direction toward the center.

10. Summary

Domain‑Driven Design is a popular architectural approach; following its four‑layer boundaries enables effective decoupling, vertical business scaling, and horizontal feature expansion.