Designing a New Project with DDD: Architecture Evolution and Bounded Contexts

1. Key Terminology

Defines common service models: IaaS (Infrastructure‑as‑a‑Service), PaaS (Platform‑as‑a‑Service), and SaaS (Software‑as‑a‑Service).

2. Architecture Evolution

The diagram shows three stages:

SaaS : Starts as a monolithic application where business logic is tightly coupled; later refactored using MVC, SSM, and layered approaches to decouple services.

PaaS : As business grows, a separate subsystem is needed; common technologies such as service mesh, SOA, and micro‑services are extracted to speed up subsystem creation.

IaaS : High‑traffic services require multiple servers across different OSes; virtualization, Docker, and Kubernetes abstract the underlying OS.

3. Bounded Context

A bounded context (BC) groups a cohesive domain model. For example, the "product" concept differs between the Order context (price, discount) and the Inventory context (stock, cost, location).

Technical implications: BCs must be aggregated at the application layer, which may require synchronous calls (e.g., Order → Inventory) or asynchronous messaging via middleware.

Guidelines for defining BCs:

Consider team size—too fine‑grained BCs increase operational overhead.

Assess semantic and functional cohesion, both business‑related and technical.

Question: Does one BC correspond to one microservice? A microservice is a deployable unit with its own technology stack, but a BC may map to multiple microservices or be combined depending on traffic and cohesion.

4. The Four DDD Boundaries

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

Second Boundary : The bounded context forms a physical process isolation layer within the solution space.

Third Boundary : Inside each BC, apply layered architecture (interface, domain, application, infrastructure) to achieve minimal coupling.

Fourth Boundary : Use aggregates in the domain layer to preserve model integrity.

5. Clean Layered Architecture

The clean architecture separates interfaces from implementations, keeping the domain layer independent of technical details. Domain logic resides in the domain layer, while infrastructure concerns (databases, external services) are injected via interfaces, enabling easy swapping and better testability.

6. Hexagonal Architecture

Passive adapters : Access external resources such as storage or third‑party services.

Active adapters : Handle input from UI, command line, or other user‑driven sources via controllers.

All interactions are expressed as ports and adapters, forming a polygon‑shaped diagram often called the "six‑sided" architecture.

7. Onion Architecture

Extends the hexagonal model by further separating the inner layers into application services, domain services, and the domain model itself.

Build applications around an independent domain model.

Define interfaces in the inner layer; outer layers implement them.

Dependencies point inward, but outer layers may also depend directly on inner layers when appropriate.

Application code can run without the infrastructure layer, improving portability.

8. Summary

Domain‑Driven Design, when applied through its four boundaries, provides a systematic way to decouple domains, support vertical and horizontal scaling, and lay a solid foundation for future extensions. Combining DDD with clean, hexagonal, and onion architectures yields a maintainable, testable, and technology‑agnostic system.