How to Structure a New Project with Domain‑Driven Design: From Concepts to Architecture

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

1. Professional Terminology

Various Services

IAAS: Infrastructure‑as‑a‑Service

PAAS: Platform‑as‑a‑Service

SAAS: Software‑as‑a‑Service

2. Architecture Evolution

The diagram clearly shows the evolution of architecture, illustrated with three layers:

SAAS : Initially we had monolithic applications where multiple business functions were mixed without layering. As business grew, we introduced MVC, SSM, and layered approaches to decouple functionalities.

PAAS : With further growth, we wanted to separate subsystems, but building each from scratch was costly. We extracted common technologies such as mesh, SOA, and micro‑services to isolate systems and reuse them for rapid development.

IAAS : When a service (e.g., order service) experiences high concurrency and a single server cannot handle it, we need multiple servers across different OSes. Virtual machines, Docker, and Kubernetes abstract the OS differences.

3. Bounded Context

Concept of Bounded Context

BC and Business Relationship

By dividing business, e.g., an order system, we get sub‑domains: Order, Inventory, etc. The meaning of “product” differs across contexts—order context uses it for price and discount, while inventory context uses it for stock quantity and location.

BC and Technology Relationship

Sub‑domains must be aggregated at the application layer, which introduces technical solutions. For example, order‑to‑inventory communication may be synchronous, while notifications could be asynchronous, requiring message middleware.

Bounded Context Partition Rules

First consider team size to decide the granularity of BCs; overly fine‑grained BCs for small teams increase operational overhead.

After determining granularity, partition by semantic relevance, functional relevance (business‑oriented), and functional relevance (non‑business‑oriented).

Following these rules yields multiple BCs.

Does One BC Equal One Microservice?

Concept : A microservice is a deployable unit with its own technical autonomy, scaling, and release cadence, typically encapsulating a specific business capability.

Relationship : A BC represents a domain or module; highly related domains may be grouped into multiple BCs, or a high‑traffic domain may be deployed as a single microservice for performance.

4. The Four DDD Boundaries

We use the four‑layer approach for architecture design:

Divide and Conquer : DDD defines four boundaries to solidify and layer domain knowledge. The core domain, supporting domain, and business sub‑domains are split into bounded contexts (BC). Within a BC, layers are organized based on core domain knowledge.

First Boundary : Define vision, goals, problem space, core sub‑domains, generic sub‑domains (reusable), and supporting sub‑domains (e.g., reporting).

Second Boundary : In the solution space, bounded contexts act as process‑level isolation.

Third Boundary : Inside each BC, apply layered architecture: interface, domain, application, and infrastructure layers with minimal coupling.

Fourth Boundary : Introduce aggregates in the domain layer to maintain model integrity.

5. Clean Layered Architecture

The diagram shows that implementation is separated from interfaces, keeping the domain layer independent of any module. Domain logic resides here without depending on concrete technology, enabling easy swapping of the infrastructure layer and exposing services to third‑party web calls.

6. Hexagonal Architecture

Active Adaptation : Input from UI, CLI, etc., where the controller is an interface; the implementation resides within the application.

Passive adaptation refers to accessing storage devices or external services; each access is an interface with concrete implementations in middleware, keeping interfaces inside the application and implementations outside.

Every input and output is an interface with its own logic, forming a polygon‑shaped architecture often called the hexagonal architecture. Features:

Outer layers depend on inner layers, ensuring reasonable dependencies; interfaces enable dependency inversion and isolate application from implementation details.

Improved testability.

7. Onion Architecture

The onion architecture builds on the hexagonal model, further dividing the inner business logic into application service layer, domain service layer, and domain model layer.

Key points:

Build applications around an independent domain model.

Define interfaces in inner layers, implement them in outer layers.

Dependencies point inward; outer layers may depend on immediate inner layers or deeper ones.

All application code can be independent of infrastructure compilation and runtime.

8. Conclusion

Domain‑Driven Design is a popular architectural approach; by following its four boundaries, you can effectively decouple domains and provide a solid foundation for both vertical business expansion and horizontal feature scaling.