Refactoring JD Pay Android SDK: Architecture Redesign with Scene, Interactor, and UserCase

1. Payment Business Composition

The JD Pay Android SDK has grown to over 75,000 lines of pure payment code, with many business variations and complex inter‑module dependencies, making maintenance and evolution increasingly difficult.

2. Can Classic Architecture Patterns Solve the Problem?

The SDK originally used MVP, which separates UI from business logic but cannot handle the "point‑to‑line" nature of payment flows. VIPER introduces a Router that can link modules, yet still struggles with data management across many intertwined modules.

2.1 Interactor as Presenter‑Level Data Manager

Making Interactor a data manager at the Presenter level forces each Presenter to know where data for other modules comes from, leading to heavy coupling and tangled logic, especially in verification modules that have dozens of Presenter implementations.

2.2 Interactor as Global Data Manager

Designing Interactor as a global scheduler allows each module to act as a widget that only handles its own UI, delegating all external interactions to a central mechanism, thus reducing coupling.

3. Scene and Interactor – DDD Design Practice

Given the SDK’s single‑Activity, multi‑Fragment structure, the Router is lightweight; the heavy logic resides in data management and flow orchestration. The new design merges VIPER’s I and R into a unified component and splits responsibilities into Scene (domain layer) and Interactor (application layer).

Scene manages the entire business flow, holds all relevant data, and determines the next step without UI concerns.

Interactor handles user‑triggered events, forwards them to Scene, and receives processed results to update the UI.

4. UserCase

A UserCase represents a chain of business units (tasks) that execute sequentially, similar to RxJava streams. Each unit has a unique ID, input, and output, enabling precise back‑tracking and redirection.

new UserCase()
        .business(createBusinessA(), JPPRuntime.getAsyncWorker())
        .business(createBusinessB(), JPPRuntime.getMainWorkder())
        .business(createBusinessC(), JPPRuntime.getAsyncWorker())
        .business(createBusinessD(), JPPRuntime.getMainWorkder())
        .execute(new Observer() {
            @Override
            public void onComplete(@NonNull UserCase userCase) {}

            @Override
            public void onError(@NonNull Throwable throwable) {}
        });

Each business unit implements the Business interface:

public interface Business<I, O> {
    int getId();
    I getInput();
    void setInput(@Nullable I input);
    O getOutput();
    void onExecute(@NonNull UserCase userCase, @Nullable Business prev);
}

UserCase stores units in a doubly‑linked list, allowing forward and backward traversal, dynamic redirection by ID, and snapshotting of inputs/outputs for reliable rollback.

5. Business Templates

After refactor, each business scenario has its own Scene, Interactor, and a set of BusinessUnits (e.g., password verification, checkout, card binding). BusinessScene aggregates the units, while BusinessInteractor creates a UserCase from them and handles events that require coordination.

6. New SDK Architecture

The redesign organizes code around business flows (Scene + Interactor + UserCase), widgetizes business units, adopts an event‑driven model for decoupling, and extracts optional features into dynamic Gradle modules to reduce SDK size.

7. Refactor Benefits

Performance tests show the startup time dropped from an average of 7,214 ms to 3,907 ms, and the pure Java codebase shrank from 75,778 lines to 35,820 lines (a 53% reduction). Resource files also decreased significantly, leading to a lighter, faster SDK.

Overall, the architectural overhaul lowers code complexity, improves maintainability, and delivers measurable performance gains.