How Alibaba’s Detail 2.0 Platform Revolutionizes Modular Development and Front‑Back Separation

1. Current Situation and Goals

The existing Detail system suffers from collaboration inefficiency, instability, and limited extensibility. The new Detail 2.0 platform aims to improve collaboration efficiency, stability, and scalability by unifying product‑detail business, enabling horizontal reuse across other Detail and non‑Detail scenarios, and adopting modular, SDK/API‑based mechanisms with two deployment modes (composition and grouping).

2. Terminology

Module : a deployable, manageable, reusable, composable, stateless software unit that follows a unified specification and provides external interfaces.

Platform : a complete technical system and architecture offering reusability, maintainability, extensibility, and collaboration, supporting diverse business goals.

Module vs. Platform : Modules are concrete micro‑implementations, while a platform is the macro architecture; modularization is the fundamental method for building a platform.

3. Design Philosophy

Divide and Conquer : Modularization reduces complexity, improves reusability and maintainability, especially for multi‑team collaboration and rapidly changing requirements.

Framework Governance : A lightweight framework defines standards while allowing openness; it governs development without stifling innovation.

Module Granularity : A module is defined by its external contract rather than internal logic.

Platform Positioning : Detail acts as an orchestration layer for backend services rather than a core business logic layer; most business logic resides in backend service interfaces.

4. Platformization

4.1 Front‑Back Separation

Historical coupling of business logic in front‑end JS and VM templates caused complexity and poor maintainability. The solution separates backend business logic from front‑end presentation and interaction logic, exposing backend data via standardized APIs (models, security, protocols, JSON/JSONP) and allowing front‑end to focus on user experience.

4.2 Module Transformation

The platform introduces a module framework that refactors a monolithic architecture into service‑level modules. Core components include:

AbstractModule – base class for all modules, each loaded in an isolated ClassLoader.

LifecycleListener – monitors module lifecycle events.

ExtensionPoint – extensible entry declared via annotations.

Extension – base class for extension implementations.

Code Example – Module Definition

public final class ExampleModule extends AbstractModule {/*implements LifecycleListener*/
    @Override
    protected ExampleResult execute(RunData data, ModuleContext context) throws ModuleException {
        // ...
    }
}

Module Properties

#module.properties
[email protected]
[email protected],YyyModule,ZzzModule
#or [email protected],YyyModule,ZzzModule
Module-Description=anything

Lifecycle Listener Interface

public interface LifecycleListener extends EventListener {
    public void changed(Event event);
}

4.3 Code Refactoring

Business logic is reorganized into layered modules, each exposing interfaces as modules. The entire platform runs on a module container, which itself runs on an application server.

4.4 Stability

Module install/uninstall provides a protection layer.

Uninstalled modules can trigger downgrade or disaster recovery.

Pre‑install checks ensure disaster‑recovery capability.

Concurrent module execution with configurable timeouts improves performance.

Stability framework plugins integrate uniformly across modules.

Adapter layer standardizes external service stability (circuit breaking, rate limiting, timeout).

4.5 Testing System

Due to historical code layering issues, the platform rebuilt its quality assurance system with layered unit tests (DAO/Util, Service/Manager, API, UI) and introduced PowerMock for backend‑heavy modules. Automation covers all layers except UI, which still requires manual testing. Continuous integration runs relevant tests based on changed files, enforcing a regular CI pipeline.

4.6 Development Model

The platform defines comprehensive standards and processes for module development, testing, quality, release (including emergency releases), and online issue handling, covering all roles (front‑end, back‑end, test, ops). Two co‑development modes are supported:

Independent module co‑development : each partner builds a module based on a shared library (Aone), offering flexibility and strong control.

Source‑branch co‑development : multiple developers work on the same codebase via branches, enabling deep integration but increasing coordination complexity.

These modes improve developer experience and governance.

4.7 Deployment Structure

The logical architecture is decoupled from physical deployment, allowing flexible, on‑demand, composable deployment models to accommodate rapid business growth and varied team scenarios.

5. Use Cases

Successful Cases : agricultural Detail, picky‑eater Detail, Xiammi Detail (not yet launched), travel Detail partial backend APIs, etc.

Other Scenarios : high‑speed vertical businesses can deploy only required modules in independent clusters; wireless terminals can consume specific APIs or modules via MTOP; non‑Detail pages can reuse SKU or seller‑profile modules, either by direct deployment or remote service calls.