Applying Domain‑Driven Design to Microservice Architecture: Benefits, Drawbacks, and Splitting Strategies

Drawbacks of Microservices

Microservice architecture provides solid guidance for decomposition and governance, but it does not automatically solve the complexity of handling changing requirements; in many cases it even aggravates the problem. Teams often spend excessive effort identifying impacted services, negotiating responsibilities, performing costly integration testing, and managing feature toggles and gray‑release processes.

Role of DDD

When we perform the "divide" step, DDD offers three dimensions to consider: functional, quality (performance, availability), and engineering. Microservices address quality and engineering well, but give limited guidance on functional partitioning, which is why DDD has regained attention.

DDD fills the functional‑partitioning gap of microservices, making the two approaches complementary for system decomposition.

Splitting Example

Below is a concrete example of using DDD together with microservices to split a complex system.

About the Domain

We define the business scope and activities as a "domain" independent of the software system. A typical e‑commerce domain may contain sub‑domains such as Product, Order, and Inventory.

Each sub‑domain has its own meaning, so we must establish clear domain boundaries, known in DDD as "bounded contexts", which serve as architectural boundaries inside the system.

Dividing Internal Architectural Boundaries

According to "The Clean Architecture" book, system architecture is determined by internal boundaries and their dependencies, not by component communication mechanisms. Microservice calls are merely a higher‑cost form of function calls and are unrelated to the core architecture.

The most important step in splitting a complex system is to define internal architectural boundaries (bounded contexts) – the functional dimension where DDD shines. Non‑functional dimensions are considered later to exploit microservice advantages.

For example, three contexts A, B, and C can run in a single deployment unit (a monolith) via in‑process calls, or each can run in separate deployment units accessed remotely, which is the typical microservice style.

Benefits of Clear Boundaries

Mixing deployment units (e.g., A and B together, C separate) can be justified when C has high traffic or frequent changes. The benefits include resource isolation, use of resilience patterns (retry, circuit‑breaker, degradation), specialized technologies (e.g., Go), and independent codebases with dedicated teams and operations.

These points focus on non‑functional concerns, whereas DDD ensures logical boundaries are well defined.

Why not split A and B as well? Because early in product development we should prioritize logical boundaries; as traffic grows, we can evolve the architecture incrementally, which is the main advantage of combining DDD with microservices.

In a monolith, unclear logical boundaries make future splitting difficult. Even if a bounded context is imperfect, DDD's concept of an "aggregate root" helps evolve the model safely.

DDD models domain concepts with entities and value objects; a group of them forms an aggregate root. Aggregates enforce internal consistency, are referenced externally only by ID, and do not share database transactions, relying on eventual consistency instead.

With aggregates, upgrading a bounded context to an independent service or microservice becomes straightforward.

For more detailed guidance on microservice decomposition, refer to the linked articles.

--- End of Article ---