How to Build a Flexible Promotion Middle Platform with Componentized Design

1. Introduction

Promotion is a core domain of the Weimob New Business Operating System (WOS), deeply involved in the transaction flow to drive sales. The original promotion system used a monolithic construction model, tightly coupling business logic with promotion rules, resulting in low reusability, weak extensibility, high maintenance costs, and duplicated efforts across product lines.

2. Promotion Definition

A promotion activity satisfies predefined condition rules and provides users with discount rewards. It participates in the transaction process to achieve sales, using tactics such as full‑reduction, full‑gift, add‑price‑purchase, X‑items‑Y‑discount, free‑shipping, limited‑time discounts, etc.

3. Current Pain Points

Promotion activities have become increasingly complex, now exceeding 12 different tactics (discounts, price cuts, fixed‑price, free‑shipping, gifts, etc.). The monolithic construction model, while fast for early market capture, now suffers from:

Heavy reliance on activity types, leading to implicit product contracts and hard‑coded implementations.

Strong coupling of business and rule logic, causing low reusability and weak scalability.

High integration cost between siloed systems; upstream systems need a generic model and interface to hide structural differences.

Resource and cost waste due to duplicated development across product lines; adding new promotion tactics is expensive and slow.

4. Abstraction Directions

Abstract and reuse underlying promotion models: Identify a unified discount rule model to explicitly define discount behavior and metadata, supporting reusable discount capabilities.

Drive processes by behavior rather than business activity type: Decouple promotion activities from business activity types and let promotion behavior dictate workflow, reducing business ambiguity.

Support mixed discount results with a generic promotion capability: Allow multiple discount actions after meeting thresholds (e.g., 10% off + free shipping + coupon).

Componentize promotion elements: Design generic promotion components with explicit structures that the promotion middle‑platform backend can recognize and parse.

Generalized design: Avoid tying the solution to a specific product line or industry, enabling extension to other business lines.

Shift middle‑platform maintenance focus to underlying capabilities: Emphasize atomic promotion abilities, workflow units, and orchestration rather than specific business activities.

5. Abstract Design

5.1 Discount Rule Metadata

The core of promotion is the discount rule. By abstracting discount rule models across business lines, a flexible combination of condition and result capabilities can generate a wide variety of promotion activities. As the middle‑platform expands its condition and result capabilities, the scope grows exponentially while remaining reusable because the low‑level design does not bind to specific business or product lines.

5.2 Discount Rule Schema Design

After abstracting the core rule model, we need a schema to organize and constrain discount rules. Unlike the old design that implicitly tied rules to activity types, the schema explicitly defines rule shapes, making them extensible and decoupled from specific activities.

Maintain an enumeration of discount condition types.

Maintain an enumeration of discount result types.

Specify whether result types must be consistent.

Define calculation types (e.g., highest‑level benefit, multiple benefits per layer).

Specify supported hierarchy levels for activity rules.

5.3 Promotion Component Componentization

In the Weimob Mall product, the most common limited‑time discount configuration page includes many promotion elements with strong business attributes (e.g., activity time, applicable venues). Each promotion element can be abstracted as a component with a key and constraint structure, categorized as:

Simple component: no constraints.

Single‑choice component: one selection from predefined options (e.g., display strikethrough price).

Multi‑choice component: multiple selections allowed (e.g., applicable activities, deductible options).

Custom component: complex constraints such as the discount rule schema.

Building a promotion product becomes selecting required components from a component library and defining their constraint values.

5.4 Templating Tool (Seven‑Puzzle Activity Template Configuration)

The templating tool allows dynamic composition of components, setting component shapes, and generating front‑end page styles. It produces two data parts:

Front‑end page style schema for dynamic rendering.

Back‑end schema recognizable by the promotion middle‑platform.

Changes to most components can be applied by editing and publishing templates without redeploying the middle‑platform.

5.5 Template Building Process

The process uses abstracted promotion components to build a promotion activity template, which includes front‑end style schema and back‑end schema. The front‑end provides a JS SDK for promotion components, while the back‑end offers data conversion SDKs and schema query interfaces.

5.6 Page Rendering Flow

Front‑end requests the template ID, retrieves the associated front‑end style schema and back‑end schema, and may apply SPI extensions for special handling. The front‑end then uses the promotion component JS SDK to render the activity configuration page dynamically.

5.7 Business Integration Flow

Businesses can integrate in three ways: using the Seven‑Puzzle generated page, using their own page with the back‑end SDK, or via non‑page Open API integration. The middle‑platform processes the template schema to drive workflows, eliminating dependence on business activity types.

6. Conclusion

This paper presents the design exploration of a flexible promotion system under Weimob WOS, addressing numerous challenges of the promotion middle‑platform. It currently serves nearly 50 promotion activities across multiple internal product lines, enabling rapid and flexible promotion construction, and will continue to evolve toward more efficient middle‑platform architecture.