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

1. Key Terminology

Infrastructure‑as‑a‑Service (IaaS), Platform‑as‑a‑Service (PaaS), and Software‑as‑a‑Service (SaaS) are the three service models discussed.

2. Architecture Evolution

The diagram illustrates how architecture evolves across three layers:

SaaS : Early monolithic applications where business logic is tightly coupled. As the business grows, developers introduce MVC, SSM, and layered approaches to decouple modules.

PaaS : When business growth demands separate subsystems, teams extract common technologies (service mesh, SOA, micro‑services) to reduce the cost of building new subsystems.

IaaS : High‑traffic services (e.g., order service) require multiple servers across different OSes. Virtual machines, Docker, and Kubernetes abstract away OS differences.

3. Bounded Context

Relationship between Bounded Context (BC) and Business : In an order system, "order" forms a sub‑domain, while "inventory" forms another. The same entity (e.g., product) can have different meanings in different contexts—price and discount in the order context, stock quantity and location in the inventory context.

Relationship between BC and Technology : Sub‑domains must be aggregated at the application layer. This aggregation drives technical choices such as synchronous calls for order‑to‑inventory, or asynchronous messaging via middleware when needed.

4. Rules for Dividing Bounded Contexts

Start with team size: a very small team should avoid overly fine‑grained BCs, which would increase operational overhead.

After fixing granularity, consider semantic relevance, functional relevance (business‑oriented), and functional relevance (non‑business‑oriented) to split contexts.

The result is a set of bounded contexts ready for implementation.

5. Does One Bounded Context Equal One Microservice?

A microservice is an independently deployable unit with its own technology stack, scaling, and release cadence. A BC represents a domain or module; multiple highly related BCs can be combined into a single microservice, or a high‑traffic BC may be split into several microservices for performance.

6. The Four DDD Boundaries

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

Second Boundary : The solution space isolates bounded contexts as physical process boundaries.

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

Fourth Boundary : Introduce aggregates in the domain layer to preserve model integrity and consistency.

7. Clean Layered Architecture

The clean layered approach separates implementation from interfaces, keeping the domain layer independent of any specific technology. Business logic resides in the domain, while infrastructure can be swapped without affecting the domain, enabling easy exposure of services to third‑party web calls.

8. Hexagonal Architecture

Driving Adapter : UI, command‑line, or other input mechanisms; the controller acts as an entry point, and the implementation lives inside the application.

Driven Adapter : Access to storage, external services, or middleware; each adapter implements a specific port and resides outside the core application.

All inputs and outputs are treated as ports with concrete implementations, forming a polygon‑shaped architecture that emphasizes "outside‑in" dependency direction.

9. Onion Architecture

Onion architecture refines the hexagonal model by further separating the inner business logic into application services, domain services, and domain model layers.

Build the application around an independent domain model.

Define interfaces in the inner layer; outer layers provide concrete implementations.

Dependencies always point inward, preserving the integrity of the core model.

All application code can run independently of infrastructure compilation and execution.

10. Conclusion

Domain‑Driven Design is a widely adopted architectural approach. By following the four DDD boundaries—vision, bounded contexts, layered isolation, and aggregates—teams can achieve strong domain decoupling and lay a solid foundation for both vertical (business) and horizontal (functional) scaling.