Practical Guide to Microservice Splitting: Necessity, Timing, Principles, and Implementation Steps

Introduction – Domain‑Driven Design (DDD) gives theoretical guidance for microservice decomposition, but in mature projects the need for further splitting is rare; the article explores why and when it becomes necessary.

1. Necessity of Splitting – Splitting helps decouple business domains, reduce system complexity, improve development efficiency, and enhance overall project quality by preventing tangled code, long test cycles, and hidden bugs.

2. Validating the Split Idea

Use an Event Storming workshop to produce a Context Mapping that reveals domain boundaries and relationships.

Analyze data tables to identify domain concepts and detect unreasonable table designs.

3. Choosing the Right Timing

When a major business adjustment or evolution is imminent.

When the core business of a service changes infrequently, allowing the split to proceed without disrupting ongoing feature development.

4. Splitting Principles

Define clear upstream‑downstream relationships; downstream may depend on upstream, but not vice‑versa.

Communicate downstream impact on upstream via domain events.

Limit a single transaction to one aggregate.

Handle frontend data adaptation in a BFF layer, keeping services focused on their own context.

5. Detailed Steps

5.1 Adjust code structure and analyze module dependencies – Separate code by business context, use IDE tools to visualize package dependencies, and locate cross‑aggregate SQL queries.

5.2 Add test protection – Ensure contract tests and interface‑level tests exist to guard against regressions.

5.3 Eliminate business code dependencies – Refactor shared utilities, move code to correct packages, replace direct data‑table access with interface calls, and encapsulate entity nesting via aggregate interfaces.

5.4 Separate unit‑test code – Move function‑level tests to their packages and handle integration‑style tests that use in‑memory databases with proper data preparation.

5.5 Handle cross‑aggregate SQL and data redundancy – Identify fields that belong to other domains, decide whether to duplicate them or redesign queries.

5.6 Split services and introduce a BFF with feature toggles – Keep existing service interfaces unchanged, create new services for the upstream code, promote neutral adaptation code to the BFF, and use toggles to switch traffic safely.

5.7 Split the database – Clone the existing database, synchronize data, point the new service to its own database, and clean up redundant tables after stability.

Conclusion – Microservice splitting is essential when it solves concrete pain points; it requires deep business understanding, clear principles, and careful timing to avoid unnecessary work and maintain system quality.