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

We often hear about Domain‑Driven Design (DDD) and understand its basics, but how can we start a new project from scratch using DDD for partitioning and architectural design?

1. Professional Terminology

IAAS : Infrastructure‑as‑a‑Service, providing basic infrastructure.

PAAS : Platform‑as‑a‑Service, offering a platform for application development.

SAAS : Software‑as‑a‑Service, delivering software over the internet.

2. Architectural Evolution

From the diagram it is easy to see the evolution process. Three layers are illustrated:

SAAS : Initially we have a monolithic application where multiple business functions are mixed without layering. As the business grows, we separate concerns using MVC, SSM, or layered approaches to decouple functionalities.

PAAS : When business expands, creating a new subsystem from scratch becomes costly. We extract common technologies such as service mesh, SOA, or micro‑services to isolate systems and reuse these technologies for rapid subsystem construction.

IAAS : For high‑concurrency services like an order service, a single server is insufficient. Deploying multiple servers across different OSes (Windows, Linux, macOS) requires OS abstraction, leading to the use of VMs, Docker, and Kubernetes.

3. Bounded Context

Relationship between BC and Business : For example, in an order system, “order” is a sub‑domain, while “inventory” is another. The same entity (e.g., product) can have different meanings in different sub‑domains.

Relationship between BC and Technology : Sub‑domains need to be aggregated at the application layer. Some interactions (order‑to‑inventory) may be synchronous, while others require asynchronous messaging, introducing middleware or other technical solutions.

Bounded Context Division Rules

First consider team size to decide the granularity of BCs; overly fine granularity for a small team burdens operations and deployment. After setting granularity, split based on semantic relevance, business‑oriented functional relevance, and non‑business functional relevance, resulting in multiple BCs.

Is a BC a Microservice?

Microservices are deployment units with high cohesion, technical autonomy, independent scaling, and independent release cycles. A BC represents a domain, module, or business capability; highly related domains may be combined into one microservice, or a high‑traffic domain may be deployed as a dedicated microservice for performance.

4. The Four‑Layer Boundaries of DDD

Using the four boundaries, DDD structures architecture as follows:

Divide and Conquer : By planning four boundaries, DDD solidifies and layers domain knowledge. The core domain and supporting domains are identified; within business domains, multiple bounded contexts are created, each further layered according to core knowledge.

First Boundary : Define project 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 physical process‑level isolation.

Third Boundary : Inside each bounded context, apply layered architecture: interface layer, domain layer, application layer, and infrastructure layer.

Fourth Boundary : Within the domain layer, introduce aggregates as the minimal unit to ensure domain integrity and consistency.

5. Clean Layered Architecture

The diagram shows that the domain layer is kept independent from any specific module by separating implementation from interfaces. The domain layer contains business logic without depending on concrete technology, allowing easy replacement of the infrastructure layer and providing services to third‑party web calls.

6. Hexagonal Architecture

Active Adapters : Input from UI, CLI, etc.; the controller is a kind of port, and its implementation resides inside the application.

Passive Adapters : Access to storage devices, external services, etc.; each access is a port whose concrete implementation is an external middleware.

All inputs and outputs are ports with concrete logic, forming a polygon‑shaped architecture. The outer layer depends on the inner layer, promoting interface‑driven design and better testability.

7. Onion Architecture

Onion architecture extends hexagonal architecture by further separating the inner business logic into application service layer, domain service layer, and domain model layer.

Key features:

Build applications around an independent domain model.

Inner layers define interfaces; outer layers implement them.

Dependencies point toward the center, ensuring that outer layers may depend on inner ones but not vice versa.

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

8. Summary

Domain‑Driven Design is a popular architectural approach. By following DDD’s four‑layer boundaries, you can effectively decouple domains, providing a solid foundation for both vertical business expansion and horizontal functional scaling.