Shared-Module Extraction — refactor-chain · backend lane · step 08/09

Bundle: refactor-chain (self-diagnosing, self-healing fix-it pipeline). Phase: do-the-work · Prerequisite: refactor-backend-07-api-naming · Next: refactor-backend-09-code-optimize. Adaptivity / conditional: repo-agnostic — any multi-module Maven or Gradle project with (or ready to gain) a shared <project>-common module. Spring idioms below are examples, not requirements.

Purpose

This step finds shared, dependency-free code that is stranded inside feature modules — the six universal package families util, cache, constant, enums, exception, and config — and migrates it into the project's shared common module so every module can use one copy. Each candidate file is classified by mechanical dependency analysis (grep results, not vibes) into EXTRACT (moves automatically), EVALUATE (user decides), or RETAIN (stays put — anything coupled to a service or data-access layer). Migration is file-by-file with immediate verification, then the build files are rewired: source modules depend on common, and common gains exactly the third-party libraries the moved files need. Business logic never moves and nothing is renamed.

When to use

• After naming is stable (step 07) and before the code-quality pass (step 09) — moving files after renames means references only need updating once.
• When the user says "extract the common module", "consolidate shared utilities", "why is DateUtils copy-pasted in three modules", or "common package check".
• Check-only mode is available: classify and report without moving anything.