# Refactoring Plan: PaymentService.java (Java Monolith) ## Phase 0 — Signal Screen [PASSED] | Input: Code description with explicit structural details | Languages: Java | Intent: Explicit — refactor monolithic payment service to support extensible provider model --- ## Phase 1 — Code Ingestion ``` +--------------------------------------------------------------------------------+ | PHASE 1 — CODE INGESTION | +--------------------------------------------------------------------------------+ | Language/Framework: Java / Unknown Spring version (inferred) | Build: Unknown | | Size: 1 file / ~2400 LOC (category: 1K–10K) | | Architecture: Monolithic Blob — no layering detected [CONFIRMED] | +--------------------------------------------------------------------------------+ | ANTI-PATTERNS | SEV | Instances | Confidence | Location | +--------------------+------+-----------+---------------+-----------------------+ | God Class | SEV-1| 1 | [CONFIRMED] | PaymentService.java | | Missing Tests | SEV-1| 1 | [CONFIRMED] | Entire service | | Missing Abstraction| SEV-2| 3+ | [CONFIRMED] | HttpClient, DB, Logger| | Static Cling | SEV-2| Unknown | [PROBABLE] | PaymentService.java | | Tight Coupling | SEV-2| 4+ | [CONFIRMED] | CC, PayPal, Stripe, | | | | | | Bank — all concrete | | Shotgun Surgery | SEV-3| Unknown | [PROBABLE] | Adding new provider | | | | | | likely touches many | | | | | | methods | +--------------------+------+-----------+---------------+-----------------------+ | TOP 3 PRIORITY: | | 1. God Class (PaymentService.java) — 2400 LOC, 42 methods, zero cohesion. | | All risk is concentrated in a single untested class. | | 2. Missing Tests — No safety net exists. Any change is a blind touch on a | | live wire. Characterization tests are MANDATORY before first edit. | | 3. Missing Abstraction — Direct instantiation of HttpClient, DB, Logger inside | | business logic makes provider extraction impossible without surgery. | +--------------------------------------------------------------------------------+ ``` --- ## Phase 2 — Dependency Mapping ``` +--------------------------------------------------------------------------------+ | PHASE 2 — DEPENDENCY MAPPING | +--------------------------------------------------------------------------------+ | INTERNAL: Module | Fan-In | Fan-Out | Instability | Zone | +--------------------------+--------+---------+-------------+-------------------+ | PaymentService.java | [INSUFFICIENT DATA — consumer | | | | count unknown from description]| [ZONE UNKNOWN] | | CreditCard logic (inline) | 0 | N/A | N/A | Embedded | | PayPal logic (inline) | 0 | N/A | N/A | Embedded | | Stripe logic (inline) | 0 | N/A | N/A | Embedded | | Bank Transfer (inline) | 0 | N/A | N/A | Embedded | +--------------------------+--------+---------+-------------+-------------------+ | NOTE: Internal structure is fully embedded — no module boundaries exist. | | Fan-in on PaymentService itself is [INSUFFICIENT DATA] without caller audit. | +--------------------------------------------------------------------------------+ | EXTERNAL: Library | Version | Status | Replacement | Effort | +---------------------+----------+-----------+-----------------+-----------------+ | Stripe SDK | Unknown | [PROBABLE: active]| N/A — keeping | Low once | | | | | | abstracted | | PayPal SDK | Unknown | [PROBABLE: active]| N/A — keeping | Low once | | | | | | abstracted | | HttpClient | Unknown | [INSUFFICIENT DATA]| OkHttp/ | Medium | | | | | Apache HttpClient| | | DB Connection | Unknown | [INSUFFICIENT DATA]| HikariCP/ | Medium | | | | | Spring Data JPA | | +---------------------+----------+-----------+-----------------+-----------------+ | HOTSPOTS: | | 1. PaymentService.java — ALL outbound dependencies route through this class. | | Every provider, every infrastructure concern. Maximum blast radius. | +--------------------------------------------------------------------------------+ | CIRCULAR DEPENDENCIES (BLOCKING): None detected [PROBABLE — no imports visible]| | ⚠ Cannot CONFIRM absence without seeing actual import graph. | +--------------------------------------------------------------------------------+ ``` ⚠ **Manual dependency audit recommended before Phase 6.** Suggested tool: `jdeps` (JDK built-in) or IntelliJ Dependency Matrix to confirm fan-in on PaymentService. --- ## Phase 3 — Risk Assessment ``` +--------------------------------------------------------------------------------+ | PHASE 3 — RISK ASSESSMENT | +--------------------------------------------------------------------------------+ | Component | Complexity| Coverage | BlastRad | ExtDep | Score | +-------------------+-----------+----------+----------+--------+----------------+ | PaymentService.java| 4 (2400 | 4 (0% | 4 (all | 3 | 3.80/4.0 | | (full class) | LOC,42m) | → score | payment |(multi- | CRITICAL | | | | inverted)| flows) |vendor) | | +-------------------+-----------+----------+----------+--------+----------------+ | Bank Transfer logic| 3 | 4 | 2 | 1 | 2.65/4.0 [EST] | | (inline) | | | | | HIGH | +-------------------+-----------+----------+----------+--------+----------------+ | PayPal logic | 2 | 4 | 3 | 2 | 2.80/4.0 [EST] | | (inline) | | | | | HIGH | +-------------------+-----------+----------+----------+--------+----------------+ | Stripe logic | 2 | 4 | 3 | 2 | 2.80/4.0 [EST] | | (inline) | | | | | HIGH | +-------------------+-----------+----------+----------+--------+----------------+ | Credit Card logic | 3 | 4 | 4 (PCI) | 2 | 3.40/4.0 [EST] | | (inline) | | | | | CRITICAL | +-------------------+-----------+----------+----------+--------+----------------+ | Weights: Complexity×0.30 | (1-Coverage)×0.25 | BlastRad×0.25 | ExtDep×0.20 | | [EST] = ESTIMATED — zero test visibility forces worst-case coverage assumption | +--------------------------------------------------------------------------------+ | HIGHEST RISK (refactor LAST): | | 1. Credit Card logic — 3.40/4.0 — PCI-DSS blast radius, zero coverage, | | highest compliance stakes. Requires PCI review at extraction. | | 2. PaymentService.java as whole — 3.80/4.0 — do not touch directly until | | abstraction layer and characterization tests are in place. | +--------------------------------------------------------------------------------+ | LOWEST RISK (refactor FIRST): | | 1. Bank Transfer logic — 2.65/4.0 — lower external dependency, lower | | transaction volume assumed, better entry point for extraction practice. | +--------------------------------------------------------------------------------+ ``` --- ## Phase 4 — Refactoring Strategy ``` +--------------------------------------------------------------------------------+ | PHASE 4 — REFACTORING STRATEGY | +--------------------------------------------------------------------------------+ | PRIMARY: Branch by Abstraction + Strangler Fig (hybrid) | | Confidence: [CONFIRMED — forced by constraints] | | Timeline: 7–10 weeks | Team: 2 backend engineers + 1 QA | Preconditions: | | (1) Characterization tests in place, (2) PaymentProvider interface defined, | | (3) Feature flag infrastructure available, (4) PCI review scheduled | | | | Justification: The God Class cannot be safely strangled from the outside | | because there are no seams — all providers are directly embedded. Branch by | | Abstraction creates the seam first (PaymentProvider interface), then the | | Strangler Fig progressively reroutes traffic to clean implementations behind | | it. This preserves production safety at every step. [CONFIRMED from Phase 1/3] | +--------------------------------------------------------------------------------+ | REJECTED: Strategy | Why Rejected | +---------------------------+--------------------------------------------------+ | Big Bang Rewrite | 2400 LOC, 0 tests = catastrophic risk. Rule 8 | | | prohibits Big Bang above 2K LOC. [CONFIRMED] | | Pure Strangler Fig | No external seam