Assembly-Style Development and Componentization in Backend BFF

Introduction

In the later stage of the Internet era, relying solely on manpower for development is no longer competitive. Systems must become reusable, composable, and adaptable to large‑scale, multi‑industry customization demands.

Business Background

Meituan to Store is a local‑service platform that connects consumers and merchants through information. A search for “haircut” displays merchant listings with deal summaries, address modules, business info, product shelves, membership cards, stylist info, etc. The product exhibits three core characteristics:

Feature abundance : The same content appears in many places (home, search, detail, order), resulting in thousands of display functions.

Large variance : Identical content follows different display rules across industries, clients, pages, versions, or user conditions.

Frequent change : Product logic iterates constantly due to user‑experience sensitivity, low standardization of local‑service content, and shifting product responsibilities.

Development Challenges

Developers of the display side build a Backend‑for‑Frontend (BFF) service that fetches raw data, transforms it according to product rules, and returns a presentation model to the client. The key challenges are:

Efficiency : Deliver numerous product features quickly with limited manpower.

Complexity : Avoid duplicated if…else… logic and keep code understandable.

Operational cost : Reduce the number of APIs and maintenance effort.

Developer fulfillment : Provide engineers with intellectually satisfying work instead of repetitive glue code.

The root cause is a mismatch between a process‑oriented development paradigm (direct translation of PRDs) and business needs for speed, diversity, and adaptability.

Problem Analysis and Solution Idea

Standardization and Assembly

John Ousterhout observes that complexity arises from ambiguity and dependency. By abstracting, decomposing, iterating, and refining concepts, ambiguity can be eliminated. Decomposition splits a large problem into manageable modules (components); dependency management defines contracts between modules.

Assembly‑style development breaks a system into highly standardized, reusable, replaceable, and autonomous components that are later assembled into a full system. The core logic is code reuse based on standardization.

Solution Focus

Two technical focuses are applied to the information‑display domain:

Granularity control : Design a multi‑level, multi‑granularity component hierarchy.

Variability modeling : Model change points so components can adapt flexibly.

Practice of Standardization and Assembly in Backend BFF

Product Function Series

Functions are grouped into “series” to reduce overall system complexity and to create a production line for assembling functions. Classification uses three dimensions:

Content‑based : Separate modules by primary displayed content (e.g., store info vs. product info).

Style‑based : Distinguish modules by UI style (e.g., product detail vs. product shelf), which influences data schema.

Implementation‑based : Group modules that share similar processing steps or dependencies.

Interface Standardization

Within a series, logical differences remain in display models and internal implementations. The approach standardizes the interface model and unifies a business identity to bridge these differences. Rare special fields are handled via a key‑value structure, reducing field variations across functions.

Function Component Extraction and Pre‑Assembly

Domain‑Driven Design is unsuitable for cross‑domain information‑display systems. Instead, existing workflow steps are analyzed, related functions are grouped, each group is encapsulated as a component, and components are composed into a series.

Example – building a product shelf:

Query product IDs based on criteria (e.g., store‑level group‑buy IDs).

Aggregate product attributes such as title, price, service flow, promotions, tags.

Query shelf filter data and placement rules (e.g., recommendation, hot‑sale, new‑arrival tags).

Assemble the final presentation model, including title/tag concatenation.

Each step is implemented as a reusable component with a standard interface. At runtime a sub‑graph of the pre‑assembled activity graph is selected, avoiding extensive conditional logic.

Variability Modeling

Large‑granularity components become unstable when many variations exist. Stability is achieved by separating stable core logic from change points and exposing the latter as configurable extension points.

Three concepts are introduced:

Variation point : An abstract extension interface where behavior may change.

Option : A concrete implementation of a variation point, reusable across contexts.

Configuration item : Parameter values that drive the selected option.

Example – title assembly: different industries require different concatenation rules (e.g., “service type + product name” vs. “service feature + product name”). Options implement each rule; configuration items select the appropriate option at runtime.

Visual Assembly and Configuration Filling

Traditional development required writing glue code, following PRDs, and manually filling presentation models. Assembly‑style development replaces this with a two‑phase process:

Component development : Abstract and encapsulate reusable functional units.

Assembly & integration : Choose required components, select feature options, and fill configuration items; the assembled result is saved and deployed without additional coding.

The workflow consists of three steps: select functions, select feature options, and fill configuration. A business identity links the selected components and configurations, enabling differentiated assembly while sharing the same component instances at runtime.

Results

Assembly‑style development resolves the initial challenges:

Both large‑granularity functional components and fine‑granularity feature components achieve high reusability and adaptability, yielding at least a 50% increase in development efficiency.

Component size is kept small, reducing cyclomatic complexity to under 10 per component.

Interface count dropped from hundreds to single‑digit numbers, dramatically lowering maintenance cost.

Developers now focus on component design rather than repetitive glue code, turning “physical labor” into “intellectual work” and improving job satisfaction.

References

Pattern: Backends For Frontends – https://samnewman.io/patterns/architectural/bff/

GraphQL and Metadata‑Driven Architecture in Backend BFF – https://mp.weixin.qq.com/s?__biz=MjM5NjQ5MTI5OA==∣=2651762036&idx=1&sn=744a07b22a3988b93403c34c4dd3ec1e&scene=21#wechat_redirect

Ford T‑Model: Success and Failure of Standardization – https://zhuanlan.zhihu.com/p/29793053

Designing Business Architecture for Assembly‑Style Development – https://www.infoq.cn/article/uk_txzgPb03mxpme4uJt

Meituan’s Slogan “Pursuing Truth with Science and Engineering” – https://www.zhihu.com/question/309806729/answer/585745193

叶柏林. 标准化. 中国科学技术出版, 1988.

Alan W. Brown. 大规模基于构件的软件开发. 机械工业出版社, 2003.

Thomas S. Kuhn. 科学的革命结构. 北京大学出版社, 2012.

John Ousterhout. A Philosophy Of Software Design, 2018.

Tassio Vale et al. Twenty‑eight Years of Component‑based Software Engineering, JSS, 2016.

Rafael Capilla, Barbara Gallina et al. Opportunities for Software Reuse in an Uncertain World, SE&P, 2019.

Peter Naur, Brian Randell et al. Software Engineering, NATO Science Committee, 1968.