Applying Domain‑Driven Design: Bounded Contexts, Four‑Layer Boundaries, and Architectural Patterns

Preface

We have all heard of DDD and understand its basics; this article shows how to divide and design a brand‑new project from scratch following the DDD process.

1. Professional Terminology

IAAS: Infrastructure‑as‑a‑Service

PAAS: Platform‑as‑a‑Service

SAAS: Software‑as‑a‑Service

2. Architecture Evolution

The diagram illustrates the evolution of architecture across three layers:

SAAS : Initially a monolithic application with tangled business logic; as the business grows, we split it using MVC, SSM, layered approaches to achieve decoupling.

PAAS : When business expands, we need a new subsystem but rebuilding from scratch is costly; we extract common technologies (mesh, SOA, micro‑services) to isolate systems and reuse them for rapid construction.

IAAS : High‑traffic services (e.g., order service) require multiple servers across different OSes; virtualization, Docker, and Kubernetes abstract the OS differences.

3. Bounded Context

Concept of Bounded Context (BC) and its relationship with business:

By dividing business domains—e.g., order, inventory—each sub‑domain interprets the same entity (product) differently. In the order context, a product represents price and discount; in the inventory context, it represents stock quantity, cost, and location.

Relationship with technology:

Aggregations across sub‑domains happen at the application layer, prompting technical solutions such as synchronous calls for order‑to‑inventory, or asynchronous messaging via middleware.

Rules for dividing BCs:

Team size determines granularity; too fine‑grained BCs burden operations. After setting granularity, consider semantic and functional relevance (business‑oriented vs. non‑business) to finalize BCs.

Is a BC a micro‑service?

Micro‑services are independently deployable units with their own technology stack, elasticity, and release cadence. A BC represents a domain or module; multiple closely related BCs may be combined into one micro‑service, or a high‑traffic BC may be deployed as a dedicated micro‑service.

4. Four‑Layer Boundaries of DDD

DDD uses four boundaries to structure the system:

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

Second boundary : Bounded Contexts act as physical process isolation within the solution space.

Third boundary : Inside each BC, a layered architecture separates interface, domain, application, and infrastructure layers.

Fourth boundary : Introduce aggregates in the domain layer to ensure model consistency.

5. Clean Layered Architecture

The diagram shows that the domain layer is kept independent by separating implementation from interfaces; domain logic does not depend on specific technologies, allowing easy replacement of the infrastructure layer while exposing services to external callers.

6. Hexagonal Architecture

Active adapters : UI, command‑line, etc., where the controller is an entry point; both the port and its implementation reside inside the application.

Passive adapters : Access to storage, external services; each access is a port with concrete middleware implementations outside the core.

Characteristics:

Outer layers depend on inner layers, enforcing dependency direction; interfaces are used to decouple application logic from details.

Improved testability.

7. Onion Architecture

The onion architecture extends the hexagonal model by further separating the inner business logic into application services, domain services, and domain models.

Characteristics:

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 any inner layer.

Application code can run independently of infrastructure.

Conclusion

Domain‑Driven Design is a popular architectural approach; by following its four‑boundary model, teams can achieve clear domain separation and lay a solid foundation for both vertical business expansion and horizontal functional scaling.