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

We have all heard of DDD and now we will discuss how to start a new project by applying DDD’s process of decomposition and architectural design.

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 : early monolithic applications, later split by MVC/SSM/layered approaches to decouple business logic.

PAAS : as business grows we extract a subsystem; to avoid high cost we reuse common techniques such as mesh, SOA, micro‑services.

IAAS : when a single server cannot handle load, we add multiple OS‑agnostic servers using VM, Docker, Kubernetes, etc.

3. Bounded Context

Concept of bounded context (BC) and its relation to business:

For example, an order system has an order sub‑domain and an inventory sub‑domain; the same entity product means different things in each context (price vs. stock).

Relation to technology:

Different sub‑domains need to be aggregated at the application layer, which leads to technical choices such as synchronous calls for order‑to‑payment and asynchronous messaging for other interactions.

Rules for dividing bounded contexts include team size, semantic and functional cohesion, and avoiding overly fine granularity that would hurt deployment and maintenance.

Is a BC equivalent to a micro‑service?

Micro‑services are independently deployable units with their own technology stack, scaling, 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 split into several services.

4. The Four DDD Boundaries

The four boundaries help to structure the architecture:

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

Second boundary : the bounded context forms a physical isolation layer.

Third boundary : inside each BC, apply layered architecture (interface, domain, application, infrastructure).

Fourth boundary : within the domain layer, use aggregates to keep model consistency.

5. Clean Layered Architecture

The diagram shows that the domain layer is isolated from infrastructure by interfaces, allowing the domain model to remain independent of specific technologies.

6. Hexagonal Architecture

Active adapters handle UI, CLI, etc.; passive adapters handle databases, external services. The application core depends only on ports, while adapters implement those ports.

Benefits:

Outer layers depend on inner layers, enabling clean dependency direction.

Improved testability.

7. Onion Architecture

Extends the hexagonal model by separating the inner business logic into application services, domain services, and domain models, with dependencies pointing inward.

Conclusion

Domain‑Driven Design is a popular architectural approach; by following its four boundaries you can decouple domains, support vertical and horizontal scaling, and lay a solid foundation for future growth.