Component-Based Development: Architecture, Implementation, and Benefits in Feed Flow

1. Introduction

Component-based development (CBD) leverages reusable software components to design and build systems, enabling minimal, efficient delivery. The Platform Basic Experience team abstracted business logic into components to quickly construct the product feed, achieving a two‑fold increase in development efficiency.

2. Background

The team was responsible for the ZhaiZhai App and mini‑program iterations. By the end of 2021, the feed rendering time was a bottleneck for the Spring Festival release, prompting a search for a scalable solution. In March 2022 a new component‑based workflow was devised, and by September 2022 it was applied broadly to over twenty feed upgrades.

3. Current Situation Analysis

3.1 Integration and Development Process

After requirement review, an interface review follows, then development. Real‑world observations revealed frequent “small incidents” such as mismatched UI fields, differing image sizes across platforms, and inconsistent naming, which caused extra work for QA, native, and FE teams.

3.2 Project Progress

Technical assessments suggested many logic pieces could be reused, but in practice new code conflicted with legacy code, leading to bloated data‑conversion layers and missed delivery deadlines.

3.3 Problem Summary

Version, terminal, and UI differences increase code complexity.

Inconsistent interface field naming leads to explosion of fields.

Rapid product iteration makes monolithic rendering logic hard to maintain.

Repeated work and long schedules raise delay risk.

3.4 Problem Entry Points and Solutions

Key entry points include grouping identical RPC modules and data‑rendering logic into components, decoupling serial rendering, and extracting version/terminal/AB‑test handling from core logic. The proposed solution is to adopt component‑based development.

4. Diving into Component‑Based Development

4.1 Component Definition

A component aggregates related logic and data, exposing a complete API while hiding internal implementation.

4.2 Component Classification

By function: technical vs. business components.

By layer: framework, platform, generic management, domain‑specific, industry‑specific, personalized.

By source: open‑source, commercial, self‑developed.

4.3 Component Model

The model includes interface list, naming, metadata, interoperability, custom interfaces, composition, evolution, packaging, and deployment.

4.4 Component Characteristics

Manageable: unified design, metadata, and classification.

Reusable: well‑designed and encapsulated for multiple scenarios.

Configurable: variable parameters allow adaptation without code changes.

Expandable: supports inheritance and event hooks for custom behavior.

4.5 Component‑Based Development

CBD (Component‑Based Development) originated in the late 1990s as an evolution of object‑oriented modeling, focusing on assembling reusable components rather than fine‑grained classes.

4.6 Types of Component‑Based Development

Opportunistic reuse – assembling existing components.

Reuse with development effort – customizing or creating components before assembly.

4.7 Advantages

Minimized delivery: assemble systems from existing components.

Higher efficiency: focus on change points.

Improved system quality: component quality lifts overall quality.

Cost reduction: fewer resources needed.

5. Realization Process

The team built an internal framework called StarRing , consisting of a declaration layer, a driver layer, and a business component package.

5.1 Preliminary Work

5.1.1 Unified Component Definition

Fields in interfaces are treated as components because BFF (Backend For Frontend) aggregates data and applies product rules before returning results to the front end.

5.1.2 Standardization

Standard naming for fields and UI elements reduces duplication and eases maintenance across native and front‑end teams.

5.1.3 Interface Return Structure Standardization

Fields are grouped by object type, merged by function, introduced KV structures for non‑standard fields, and extended via VOExt classes.

5.2 Component Granularity

Components encapsulate RPC calls and data‑rendering logic; examples include title, price, and discount components.

5.3 Component Class Design

Top‑level component interfaces define metadata, component type, dependency list, and a generic doHandle() method; custom components add doInnerHandle() for specific business logic.

5.4 Parameter Passing

Parameters are decoupled from RPC and component scopes, allowing each to manage only the values it needs.

5.5 Component Hit Conditions

Conditions are expressed either via an IBaseCondition implementation or EL expressions, enabling selective component activation per scenario.

5.6 Managing Multiple Component Versions

Components are described in XML configuration files, which the Spring‑Boot based framework parses to create singleton beans.

5.7 Component Ordering

Dependencies are expressed as a directed graph; a topological sort determines execution order, detecting cycles when present.

5.8 Component Driving

Two entry points exist: renderView() for single‑view rendering and renderViewList() for batch rendering, each driving the appropriate component list.

5.9 New Development Mode

Typical steps: create business components (optional), declare XML configuration, define driver beans, execute the driver, handle auxiliary logic (e.g., logging), and return results.

6. Effectiveness Data

Applying component‑based development to the feed scenario increased overall development efficiency by 2.2× (84 h ÷ 37 h). Detailed cost breakdowns are provided.

7. Supporting Ecosystem

XML auto‑completion plugin for IntelliJ.

Planned Maven scaffolding to generate boilerplate code.

8. Conclusion

Traditional development suffers from growing complexity, low reuse, and difficulty handling rapid iteration.

Component‑based development condenses functional logic into reusable units, enabling fast, high‑quality delivery.

For further discussion, contact zpc_1994 .

9. References

[1] 毕伟.组件化软件开发方法，2022. [2] Margaret Rouse. Component‑Based Development, 2015. [3] UNIC. Component‑Based Development, 2014. [4] 阚耀光. appview‑auto‑degrade‑cache, 2022. [5] 陈奇恩. Complex concurrent scheduling model at ZhaiZhai, 2022. [6] 陆晨等. GraphQL and metadata‑driven architecture in BFF, 2021. [7] Sam Newman. Backends For Frontends, 2015. [8] 谷金. Design of generic product cards, 2022. [9] 陆晨等. Standardization and assembly architecture in BFF, 2022. [10] 乐彬等. Meituan delivery platformization practice, 2022. [11] 严蔚敏, 吴伟民. Data Structures (C), 2007.