Microservice Decomposition, DDD Guidance, and Serviceization Best Practices with HSF/EDAS

Starting from a real case, the article shows how customers transform a classic layered architecture into microservices by first extracting the DAO layer, raising the question of proper decomposition and introducing Domain‑Driven Design (DDD) as the guiding principle.

DDD is described as a design philosophy that creates a shared language between developers and business people, focusing on domains, domain models, ubiquitous language, and bounded contexts, illustrated with a transfer‑money example.

The strategic and tactical aspects of DDD are covered: selecting core and supporting sub‑domains, distinguishing core, supporting, and generic sub‑domains, and mapping them to microservice boundaries.

Service splitting is presented as a vertical (business line) and horizontal (domain) process, with team considerations such as full‑stack "Two‑Pizza" teams and Conway's law, followed by a list of challenges to anticipate before implementation.

Real‑world cases from EDAS are introduced, defining key terms: HSF (High Speed Framework), EDAS (Enterprise Distributed Application Service), and VPC (Virtual Private Cloud).

In the development section, HSF's service registration and discovery mechanism is explained, showing how interfaces are declared in Spring XML, how RPC calls are made, and why asynchronous callbacks that work in a single‑process environment may fail in a distributed setting.

Best‑practice tips are listed, emphasizing small but important details such as logging, parameter validation, return values, and naming conventions.

The deployment discussion highlights VPC isolation, network segmentation, and why VPCs are preferred over simple routing for security and cross‑AZ availability.

HSF routing is described with a round‑robin selection, heartbeat monitoring, and handling of unhealthy endpoints.

Operational advice warns against extensive use of iptables, recommending VPC + NAT for most needs and cautioning about high maintenance costs.

Integration‑testing problems caused by NAT gateways, mismatched timestamps, TCP TIMEWAIT, recycle, and PAWS are analyzed, with recommendations to keep timestamps consistent, avoid recycle in production, and prefer SLB over NAT.

Performance testing reveals common pitfalls such as double JSON serialization in RPC calls and improper handling of non‑serializable HTTP objects, urging developers to assess object size and serialization suitability.

Thread‑pool saturation cases are examined; three HSF call models (synchronous, asynchronous, Future) and three thread‑pool types (IO, service, Tomcat) are explained, along with tuning strategies.

Optimization attempts (method refactoring, thread‑pool parameter increase, cloud scaling) are discussed, noting that scaling alone may not solve root causes, especially when Redis connection pools or large JSON‑encoded lists are misused.

Common microservice patterns are summarized: externalized configuration for dynamic Redis tuning, circuit breaker for rate‑limiting and degradation, distributed tracing for complex service graphs, and a broader set of architectural patterns.

The article concludes with a brief promotion of the EDAS "1‑yuan plan" for small enterprises, followed by source attribution.