How TMF2.0 Revolutionizes E‑Commerce Platforms with Full‑Link Business Identity

Overall Introduction

In 2017 Double 11, transaction peaks reached 325,000 orders per second, posing a huge challenge for the entire trading system. The system must support dozens of business units across the group, requiring faster demand response, accelerated release cycles, low entry barriers for new small businesses, self‑service extensibility, and reusable assets.

E‑commerce’s nature leads to a domain‑service‑based distributed architecture. The business lifecycle is long, covering招商, selection, supply chain, warehousing, marketing, ordering, fulfillment, logistics, after‑sale, etc., resulting in a long business chain with upstream logic influencing downstream processes. Numerous core systems (product platform, cart, order, fulfillment, discount, logistics, supply chain) and countless auxiliary services (service platform, Tmall SMC, Taobao CPC) support this chain.

Pain Points

Pain Point 1: Lack of full‑link demand management, low collaboration efficiency

Demand descriptions are often a single sentence; detailed specifications rely on later documents, emails, and clarification meetings, involving many platform developers.

Demand transmission is inefficient, requiring repeated communication and rework.

Platform capabilities are not exposed, making technical evaluation time‑consuming.

Similar demands lead to duplicate implementations as knowledge is lost over time.

Pain Point 2: High platform entry barrier, new small businesses cannot iterate quickly

Early‑stage small businesses need ultra‑simple order flows, isolated runtime code, and independent release cadence.

Pain Point 3: Business and platform are not well separated, hindering self‑service development

Vertical and horizontal business dimensions cause high coupling through shared SPI extensions.

Pain Point 4: Lack of reusable business assets

Enterprise architecture maturity can be evaluated using frameworks like TOGAF, which include the Enterprise Continuum concept.

Solution Approach (TMF2.0)

TMF2.0 addresses six key issues:

Full‑link business visibility: Analysts and engineers discuss requirements, impact analysis, and technical evaluation using a unified business language and visualized rules.

Structured demand: Leverage exposed business capabilities and existing rules to decompose demands, reducing communication cost.

Business configurability: With clear demand, configure and publish business logic online.

Integrated business testing: Automatic test case selection and execution based on code changes.

Business monitoring: Fine‑grained monitoring at the business dimension, not just transaction aggregates.

Fault troubleshooting: Quickly capture fault snapshots, reproduce incidents, and locate root causes.

Key Design Ideas

Plugin‑based architecture separating business packages from the platform: The platform provides a plugin registration mechanism; business code resides only in plugins, strictly isolated from platform code. Business packages are delivered as separate artifacts.

Unified business identity across the full link: Each business instance receives a unique identifier (similar to an ID card) based on person, goods, and venue dimensions, enabling isolation between business flows.

Separation of management and runtime domains: Business definitions (lifecycle, identity, objects) are managed in the management domain and then pushed as configuration files to the runtime domain, where they are parsed into executable commands.

Plugin Architecture Layers

The architecture consists of three layers:

Business specification layer: Defines transaction models, domain partitions, and configuration items, providing reusable interfaces, processes, and models.

Solution layer: Encapsulates market‑specific solutions (e.g., marketing modes) that reuse common implementations.

Business customization layer: Assembles customized packages for specific market needs based on the lower‑level specifications.

Unified Business Identity

The identity abstracts three dimensions—person, goods, venue—to uniquely tag each business transaction. A UIL‑based identification scheme models samples, buyers, sellers, and categories, covering 99% of products.

Management vs. Runtime Domain Separation

Management defines business identity, overlay relationships, and conflict decisions; the runtime executes the defined rules. Business complexity arises from vertical (industry) and horizontal (product) dimensions, leading to a rule set composed of one vertical collection plus N horizontal collections.

Key Models

The TMF2.0 key models include the business configuration line and the business runtime line. The configuration line uses ability‑domain models to expose structured capabilities, which are then templated, saved, and pushed to the runtime line.

Based on these models, the platform achieves visualized business definitions, instant configuration, versioned configuration management, and multi‑tenant isolation.

Operations & Stability by Business Dimension

With business identity in place, reliability can be ensured per business dimension:

Fault monitoring per business, enabling early detection of issues in low‑traffic new services.

Cluster deployment per business, allowing independent upgrades without affecting unrelated services.

Stability guarantees per business, such as QoS policies, traffic shaping, and performance baselines for each business scenario.

Transformation Results

Average development cycle reduced to 12 days (e.g., automotive 4S service completed in 7 days vs. a month before).

Platform and business decoupled: business packages exist only in business plugins, enabling flexible releases without platform changes.

Business asset library: Over 50 reusable assets have been accumulated, allowing rapid copy, adjustment, and publishing for new businesses.