How to Structure a New Project Using Domain‑Driven Design: A Step‑by‑Step Guide

Introduction

Domain‑Driven Design (DDD) is widely known, but how can a brand‑new project be partitioned and architected from scratch using DDD principles? This guide walks through the entire process.

1. Key Terminology

IAAS : Infrastructure‑as‑a‑Service.

PAAS : Platform‑as‑a‑Service.

SAAS : Software‑as‑a‑Service.

2. Architecture Evolution

The diagram below illustrates the evolution of architecture from monolithic applications to layered and service‑oriented designs.

SAAS : Initially a single monolithic app where business logic is tangled. As the business grows, MVC, SSM, and layered approaches are introduced to decouple modules.

PAAS : When business expands, a new subsystem is needed, but building it from scratch is costly. Common technologies such as service mesh, SOA, and micro‑services are extracted to isolate systems and accelerate development.

IAAS : High‑traffic services (e.g., order processing) exceed a single server’s capacity, requiring multiple servers across different OSes. Virtual machines, Docker, and Kubernetes abstract the underlying OS.

3. Bounded Context (BC)

A bounded context defines a specific domain or module. For example, an order system and an inventory system are separate sub‑domains. The meaning of “product” differs between the order context (price, discount) and the inventory context (stock, cost, location).

Technical implications: sub‑domains must be aggregated at the application layer, which introduces decisions about synchronous versus asynchronous communication, often requiring message brokers or other integration technologies.

BC division rules:

Consider team size; overly fine‑grained BCs burden deployment and operations.

After determining granularity, split by semantic relevance, business‑oriented functional relevance, and non‑business functional relevance.

Does one BC equal one microservice? A microservice is a deployable unit with its own technology stack, autonomy, and scaling characteristics. Multiple closely related BCs can be combined into a single microservice, or a high‑traffic BC may be isolated as its own microservice for performance.

4. The Four DDD Boundaries

Using the four boundaries, architecture is designed as follows:

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

Second Boundary : In the solution space, bounded contexts act as physical isolation layers.

Third Boundary : Within each bounded context, apply layered architecture (interface, domain, application, infrastructure) for minimal isolation.

Fourth Boundary : In the domain layer, introduce aggregates to preserve model consistency.

5. Clean Layered Architecture

The diagram shows a clean separation between interfaces and implementations, keeping the domain layer independent of any specific technology, which facilitates swapping infrastructure components and exposing services to third‑party callers.

6. Hexagonal Architecture

Active adapters : UI, command‑line, or other input mechanisms; controllers act as entry points, and the implementation resides within the application.

Passive adapters : External services, storage devices, or middleware; each external interaction is an adapter implemented outside the core application.

All inputs and outputs are treated as ports with concrete adapter logic, forming a polygon‑shaped architecture often referred to as the six‑sided (hexagonal) architecture.

7. Onion Architecture

Building on the hexagonal model, the onion architecture further separates the inner business logic into application services, domain services, and domain model layers.

Focus on independent domain models.

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

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

Application code can be compiled and run independently of infrastructure.

8. Summary

Domain‑Driven Design is a popular architectural approach. By following the four DDD boundaries, teams can achieve clear domain separation, facilitate vertical business expansion, and support horizontal functional scaling with a solid architectural foundation.