Applying Domain-Driven Design (DDD) from Project Initiation to Architecture Design

We have all heard of DDD and now explore how to partition and design a new project from scratch following the DDD process.

Terminology : IAAS – Infrastructure‑as‑a‑Service, PAAS – Platform‑as‑a‑Service, SAAS – Software‑as‑a‑Service.

Architecture Evolution (see image):

SAAS – early monolithic applications evolve through MVC, SSM, and layered approaches to decouple business logic. PAAS – as business grows, extracting subsystems becomes costly; common technologies like mesh, SOA, and micro‑services are introduced to isolate systems and accelerate development. IAAS – high‑traffic services require multiple servers across OSes; virtualization, Docker, and Kubernetes abstract the underlying OS.

Bounded Context (see image):

BCs map to business sub‑domains (e.g., Order, Inventory). The same entity (Product) can have different meanings in different contexts. BCs also dictate technical choices; interactions may require synchronous calls or asynchronous messaging via middleware.

Bounded‑Context Division Rules : Consider team size to avoid overly fine‑grained BCs that burden deployment. After determining granularity, split by semantic and functional relevance (business‑oriented vs non‑business‑oriented).

Is a BC equivalent to a microservice? Not necessarily; a BC represents a domain or module. Highly related domains may share BCs, while high‑traffic domains may be deployed as separate microservices for performance.

Four DDD Boundaries (see image):

1️⃣ Define vision, goals, core, generic, and supporting sub‑domains. 2️⃣ The bounded context forms a physical process isolation layer. 3️⃣ Inside each context, apply layered architecture: interface, domain, application, infrastructure. 4️⃣ Use aggregates to maintain domain integrity.

Clean Layered Architecture (see image):

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

Hexagonal Architecture (see image):

Active adapters handle UI/CLI inputs; passive adapters interact with storage or external services. All inputs/outputs are treated as ports, forming a polygon‑shaped architecture.

Onion Architecture (see image):

Extends hexagonal architecture by adding application service, domain service, and domain model layers. Core principles: build around an independent domain model, define interfaces inward, allow outer layers to depend on inner ones, and keep application code independent of infrastructure.

Conclusion : DDD is a popular architectural approach; by following its four‑layer boundaries, teams can achieve effective domain decoupling, support vertical and horizontal scaling, and lay a solid foundation for future extensions.