Applying Domain-Driven Design: Architecture Evolution, Bounded Contexts, and Layered Patterns

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

1. Terminology

IAAS: Infrastructure‑as‑a‑Service

PAAS: Platform‑as‑a‑Service

SAAS: Software‑as‑a‑Service

2. Architecture Evolution

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

SAAS: Initially a monolithic application where multiple business functions are mixed. As the business grows, we split it using MVC, SSM, layered architecture, etc., to decouple business modules.

PAAS: When business expands we want to extract a subsystem, but rebuilding from scratch is costly. We therefore extract common techniques such as mesh, SOA, micro‑services to isolate systems and reuse them for rapid construction.

IAAS: When a service (e.g., order service) reaches high concurrency a single server is insufficient. We add multiple servers (Windows, Linux, macOS) and use VM, Docker, Kubernetes to abstract the underlying OS.

For those preparing for a Java interview, the Java interview library offers over 2,000 questions covering mainstream technologies.

3. Bounded Context

Concept of bounded context (BC).

BC and business relationship: By dividing business, e.g., an order system, we get sub‑domains such as Order and Inventory. The same entity (Product) may have different meanings in different contexts – price and discount in Order, stock quantity and location in Inventory.

BC and technical relationship: Sub‑domains must be aggregated at the application layer, which introduces technical solutions such as synchronous calls for order‑to‑inventory, or asynchronous messaging via middleware.

Bounded‑context division rules:

Generally, start with team size to decide the granularity of BCs. Too fine‑grained BCs for a small team increase operational overhead. After determining granularity, split by semantic relevance, business‑oriented functional relevance, and non‑business functional relevance to obtain multiple BCs.

Recommended learning: Spring Cloud Microservice Practice (2023 edition)

4. Four Boundaries of DDD

Based on the diagram, DDD uses four boundaries to structure the architecture:

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, the bounded context acts as a physical process isolation layer.

Third boundary: Within each bounded context, apply layered architecture: interface, domain, application, and infrastructure layers, achieving minimal isolation.

Fourth boundary: Within the domain layer, introduce aggregates to guarantee consistency of domain models.

5. Clean Layered Architecture

The diagram shows that by separating implementation from interfaces, the domain layer remains independent of any module. Business logic resides in the domain model without depending on concrete technology, allowing easy replacement of the infrastructure layer and exposing services to third‑party web calls.

6. Hexagonal Architecture

Active adapters: Input sources such as UI or CLI; the controller is a kind of port, and the port’s implementation lives inside the application.

Passive adapters: Access to storage devices, external services, etc. Each access is a port whose concrete implementation is provided by middleware. All inputs and outputs are ports, forming a polygon‑shaped architecture often called the hexagonal architecture.

Characteristics:

Outer layers depend on inner layers, making dependencies logical; ports enable interface‑driven programming and isolate application from implementation details.

Improved testability.

7. Onion Architecture

The onion architecture extends the hexagonal model by further separating the inner business logic into application service layer, domain service layer, and domain model layer as defined by DDD.

Characteristics:

Build applications around an independent domain model.

Define interfaces in inner layers; outer layers implement those interfaces.

Dependencies always point toward the center, preserving a stable dependency direction.

Application code can be compiled and run independently of infrastructure.

Conclusion

Domain‑Driven Design is currently a popular architectural approach. By following its four‑boundary framework, teams can effectively decouple domains, providing a solid foundation for both vertical business expansion and horizontal functional scaling.