Splitting Monoliths into Microservices with DDD: Real Cases & Tips

1. Microservice Splitting

Starting from a real case, customers often break a classic layered architecture into microservices. The first step is to extract the DAO layer, but this raises questions about proper boundaries. Domain‑Driven Design (DDD) provides a guiding philosophy: it creates a shared language between developers and business stakeholders and focuses on business concepts such as domains, domain models, and a ubiquitous language.

Key DDD concepts include:

Domain – the business area the team focuses on.

Domain model – the abstractions that represent the domain.

Ubiquitous language – a common terminology used by both developers and business people.

Bounded Context – the limits within which a model is valid.

Strategically, DDD helps identify core domains (the essential business) and supporting or generic sub‑domains (e.g., logistics, payment, membership). After defining these, relationships between contexts (upstream/downstream, shared models, adapters) are considered.

2. Service Cases and Best Practices

Several real‑world cases from Alibaba Cloud's EDAS illustrate common challenges and solutions.

Development

HSF (High Speed Framework) provides a registry for service publishing and subscription. Services are defined by interfaces; consumers declare the interface in Spring XML, and providers implement it. After deployment, RPC calls can be made. A typical issue is asynchronous callbacks that work in a single‑process environment but fail in distributed settings.

Deployment

Customers sometimes encounter intermittent connectivity due to VPC network isolation. VPC isolates user networks and supports cross‑AZ, disaster recovery, SNAT/DNAT, and security groups. Misconfiguration can cause unreachable services.

Integration

Unstable connections may stem from TCP TIMEWAIT and recycle settings, causing packet drops when timestamps differ across machines. Recommendations include synchronizing timestamps, avoiding recycle in production, and preferring SLB over NAT.

Performance Testing

Clients sometimes compare HSF RPC with RESTful services and find performance lacking due to double JSON serialization. HSF uses binary serialization, so avoid unnecessary object‑to‑JSON conversions and be mindful of object size, enums, singletons, and generics.

Running in Production

Thread‑pool exhaustion is a common failure mode. HSF has three pools: a small IO pool, a large server‑side pool (default max 600), and Tomcat’s accept pool. Simply increasing pool sizes may not solve root causes; scaling out without understanding bandwidth and connection limits can cause crashes.

3. Common Microservice Patterns

Typical patterns include:

Externalized configuration – dynamically push configuration such as Redis connection limits.

Circuit Breaker – limit traffic and degrade gracefully during failures.

Distributed tracing – track requests across multiple services.

The article concludes that EDAS provides a comprehensive solution for building, deploying, and operating microservice systems, with a low‑cost “1‑yuan plan” for small enterprises.