Understanding Mid‑Platform Architecture: Concepts, Benefits, and Implementation Patterns

Preface

The article introduces the concept of a mid‑platform (中台) and emphasizes that its construction is not merely a technical effort. It affects the organizational structure of operations, product, and technology teams. The primary goal is to achieve flexible reuse of capabilities while minimizing the cost of expansion, thereby addressing stability and resource‑competition issues that arise in large‑scale platforms.

Technical Perspective

From a technical standpoint, the mid‑platform relies on abstraction and component‑based design to build a flexible architecture that can quickly respond to changes. This approach maximizes logic reuse and minimizes the effort required for handling differences.

Business Perspective

From the business side, a mature mid‑platform enables rapid onboarding of new business lines or integration of existing lines with shared capabilities. The focus is on delivering the best and fastest implementation of new requirements based on existing platform abilities.

Business Identity

Business identity is defined as a full‑link transmission and isolation identifier that translates business characteristics and planning into technical traits. It allows differentiated configuration, code isolation, and process orchestration, ensuring strict data and permission separation between identities.

Guidelines for applying business identity in a mid‑platform include supporting rapid changes when identities are split or merged, and ensuring that identity‑driven extensions can be quickly adapted.

Extension Points

The platform provides extension points to minimize development effort for business differentiation. These points can be abstracted and extended by business teams, with the platform offering generic implementations that can be chosen based on specific needs.

Implementation Patterns

Mode 1 – Extension JARs or sub‑projects are integrated directly into the mid‑platform. All extension points are invoked locally, offering good performance and complete code isolation, but the platform package grows large and may suffer stability issues.

Mode 2 – The platform defines only SPI interfaces; actual extensions are implemented in separate business applications and invoked remotely. This reduces platform bloat and version‑conflict risks, but incurs remote‑call overhead and less control over business implementations.

Mode 3 – Common capabilities are packaged as JARs used by business lines, while extensions remain local. This balances performance and isolation, yet requires careful version compatibility management for the shared JARs.

Architecture Diagrams

BCF Workflow and Extension Examples

The article concludes with an evolution roadmap for extension points and a call for feedback.