Microservice Splitting Done Right: DDD Strategic & Tactical Patterns from Top Tech

Most teams get microservice decomposition wrong from the first step. The author identifies three prevalent anti-patterns: splitting by technical layers (controllers, schedulers, message queues), splitting by database tables ignoring business cohesion, and over-splitting by single functions (e.g., separate services for flash-sale, points, reviews, coupons). These approaches produce a distributed monolith — services that appear independent but are deeply coupled, requiring numerous remote calls, distributed transactions, and synchronized deployments for simple changes.

Strategic DDD: Four Core Concepts That Define Service Boundaries

Strategic DDD answers how to split . It consists of four pillars:

Subdomain Classification : Separate the system into Core Domains (order, payment, inventory, settlement — independent services, dedicated clusters, highest availability), Supporting Domains (user, product, after-sales, logistics, membership — independent services, non-intrusive to core flows), and Generic Domains (messaging, file, config, auth, logging — unified infrastructure services with zero business logic).

Bounded Context : The true microservice boundary. One bounded context = one microservice . The same noun (e.g., "Order") carries different semantics in different contexts: Trading Context Order handles placement, payment, state transitions, price calculation; After-sales Context Order handles refunds, disputes; Statistics Context Order is read-only for reporting. Forcing them together seeds architectural decay.

Context Mapping : Explicitly define inter-service relationships — partnership, customer-supplier, event subscription, anti-corruption layer — to make dependencies governable, traceable, and free of cyclic calls.

Ubiquitous Language : Within a context, terminology, definitions, and state meanings are unified, eliminating "ten people, ten understandings".

Tactical DDD: Solving Intra-Service Data Consistency

Tactical DDD answers how to implement . Aggregates, aggregate roots, entities, and value objects serve a single purpose: determine which data must reside in the same service, be protected by a local transaction, and maintain strong consistency .

Core Iron Law : Strongly related, synchronously changing, must-be-consistent data → collapse into the same aggregate. Cross-aggregate, cross-context → always asynchronous events, eventual consistency.

This principle eliminates 90% of unnecessary distributed transactions at the source.

Big-Tech Standard Four-Step Decomposition Process

Used at Alibaba, ByteDance, Meituan; applicable to new systems and legacy refactors.

Business Landscape Analysis : Understand roles, flows, change frequency, dependencies. Distinguish core high-frequency paths from low-frequency stable modules.

Event Storming Modeling (DDD's strongest landing tool): Model via Command → Event → Aggregate .

User does X (Command) → produces Y (Event) → belongs to Z (Aggregate)

. Business capabilities naturally cluster; boundaries emerge without guesswork.

Bounded Context Mapping to Microservices : Each highly cohesive, loosely coupled cluster becomes an independent service. Typical e-commerce result:

Core: Trading Service, Inventory Service, Payment Service

Supporting: User Service, Product Service, After-sales Service, Logistics Service

Generic: Messaging, File, Config, Auth

Aggregate Modeling + Four-Layer Code Structure : Define aggregate roots, entities, value objects. Implement Interface / Application / Domain / Infrastructure layers. Encapsulate local transactions, isolate external dependencies, eradicate anemic CRUD models.

Traditional Wrong Split vs. DDD Correct Split

❌ Traditional (table-driven) : Order, Coupon, Points, Inventory as separate services. Placing an order requires synchronous calls to all, creating hard dependencies, hard transactions, and cascade failures — any downstream outage kills the core path.

✅ DDD (business capability + event-driven) :

Trading Domain → only order fulfillment

Marketing Domain → only coupons/points

Inventory Domain → only lock/release

Key optimization : Order main flow commits via local transaction and returns fast; domain events asynchronously trigger coupon, inventory, points. Core and non-core paths fully decoupled — marketing crash doesn't block orders, inventory latency doesn't block user purchase. Stability jumps significantly.

Five Chronic Ailments Cured After DDD Adoption

Distributed monolith eradicated — clear boundaries, closed responsibilities, no more fake microservices.

Distributed transactions drastically reduced — strong consistency local, cross-service eventual consistency, production data issues drop off a cliff.

Common-package explosion solved — domain-private models, no global dependency chaos.

Faults naturally isolated — non-core failures never drag down core trading.

Large-team parallel development enabled — one domain per squad, independent iteration, release, ops.

P7 Interview Talking Points (Verbatim)

Interviewer: How did you split your microservices? What was the basis? Early on we used crude table-driven splitting, causing severe coupling, distributed transaction sprawl, and cascading failures. Later we fully adopted DDD . Strategic level : Business landscape + event storming → core/supporting/generic subdomains → bounded contexts define service boundaries → goodbye to experience-based splitting. Context mapping standardized sync RPC vs. async event decoupling, curing chaotic calls and hard coupling at the architecture level. Tactical level : Aggregate design collapses strong-consistency business; aggregates use local transactions for reliability; cross-service uses event-driven eventual consistency, slashing distributed transaction risk. Post-adoption we achieved business fault isolation, iteration efficiency gains, and drastic link-complexity reduction , supporting sustained traffic and team growth.

High-Frequency DDD Pitfalls (Ten-Year Battle Scars)

Only applying code layering, skipping business boundary decomposition (fake DDD)

Over-splitting → service granularity explosion

Anemic domain models — all CRUD, zero domain behavior

Abusing synchronous calls, discarding event-driven thinking

Generic business logic invading core trading path

Big-bang rewrite without incremental migration

Closing Thoughts

Middleware, frameworks, tuning are table stakes for mid-level engineers. Business modeling, architecture decomposition, system governance are the dividing line for senior engineers/architects. Mastering DDD transforms you from a CRUD bricklayer into a professional with system design, architecture evolution, and fault governance capabilities — the core competency behind the salary gap.