Design and Implementation of a Modular Detail Platform at Alibaba

1. Background

Detail's current problems are described in earlier documents; the new Detail platform aims to improve collaboration efficiency, stability, and extensibility, promote unified product detail business, enable reuse across other Details and non‑Detail scenarios, and adopt modular, SDK/API approaches with synthesis and grouping deployment modes.

2. Terminology

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

Platform A complete technical system and architecture that is reusable, maintainable, extensible, collaborative, standardizes development work, and supports diverse business goals.

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

3. Design Principles

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, allowing openness while enforcing consistency, similar to managing disorderly behavior.

Module Granularity A module is defined by its external contract and compliance with the module specification, regardless of internal logic.

Platform Positioning The Detail platform acts as an orchestrator of backend services rather than containing core business logic; most logic resides in backend services, with only a small residual portion in Detail.

4. Platformization

4.1 Front‑Back Separation

Historical Detail code mixes business logic in front‑end JS and VM templates, causing complexity. The platform separates backend business logic from front‑end presentation and interaction, standardizing APIs, models, security, and protocols, enabling parallel development.

Front‑back separation does not eliminate interaction; backend business data interfaces become the communication channel, with defined models, security mechanisms, call protocols (HTTP/RPC), and response formats (JSON/JSONP), recommending native Java usage.

4.2 Module Refactoring

The module framework decouples a monolithic application into service‑level modules, providing lifecycle management, extension points, and non‑intrusive encapsulation.

Core Components

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

LifecycleListener – listens to module lifecycle events.

ExtensionPoint – extensible entry declared via annotation.

Extension – base class for extension implementations.

Code Example

1. Basic module definition (image)

2. Minimal module description (image)

3. Lifecycle definition (image)

4. Lifecycle listener (optional)

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

Module Container Publishes local interfaces as service‑oriented APIs, adds remote protocols, security wrappers, and batch processing support.

Supporting Tools IDE plugins and management utilities for module lifecycle and versioning are under development.

Plugin System Common libraries (logging, stability, validation, workflow) are packaged as plugins to ensure consistent usage across modules.

4.3 Code Refactoring

Business logic is reorganized according to the module specification, exposing interfaces as modules and running on a module container atop the application server.

4.4 Stability

Stability practices include module install/uninstall protection, downgrade or disaster recovery triggers, timeout configuration per module, and unified stability framework integration via adapters.

Module installation/uninstallation safeguards module‑level stability.

After uninstall, modules can downgrade or trigger failover.

Disaster‑recovery capability is validated before installation.

Batch execution supports concurrent modules with individual timeouts.

Stability plugins are embedded via the module framework.

Adapter layer enforces unified stability controls for external services.

4.5 Testing System

Layered testing aligns with code layers (service, business, API, UI). Automated tests use PowerMock; UI tests remain manual. Continuous integration runs relevant tests based on changed classes.

4.6 Development Model

Comprehensive standards cover module development, testing, quality, release, and incident handling, supporting both independent module co‑development and source‑branch co‑development.

Two collaboration modes are offered: independent module co‑building using shared libraries, and source‑branch co‑building with multiple branches merging into a unified deployment.

4.7 Deployment Structure

The logical platform architecture is decoupled from physical deployment, allowing flexible, composable deployment models tailored to business needs.

5. Use Cases

Successful cases include full‑detail support for agriculture, food, and travel, as well as partial backend interfaces for other scenarios. The platform also supports remote service integration for mobile or HTML5 clients and reusable modules for SKU or seller profile pages.