Challenges of Abstraction and Reuse in Business Middle‑Platform Development

The author opens with a philosophical anecdote about Plato’s definition of a human and Diogenes’ literal interpretation, using it to illustrate the gap between abstract ideas and concrete reality in software development.

Plato defined a human as a two‑legged, hairless animal; Diogenes responded by presenting a featherless chicken, asking “Is this a human?”

Having worked in development for years, the author admits that while many design concepts (GOF patterns, DDD, aggregates, domain services, bounded contexts) are well‑known, applying them in real projects often feels like “learn once, discard quickly.”

Abstract vs. Concrete Challenges

Books illustrate abstraction with animal examples (e.g., “animal‑abstract, chicken‑duck‑dog‑instance”), which help grasp ideas but feel distant from daily work. When abstracting concrete business processes (e.g., various shipping scenarios), the mapping can easily go off‑track, leading to the internal saying “the front line has a deity” to avoid mis‑abstraction.

The author’s department is a business middle platform covering orders, products, marketing, and payments. Its core value is to increase efficiency through reuse, ensuring that a feature serves at least two scenarios.

However, abstracting is not trivial: extending a system often means reserving placeholders, but predicting future business changes is hard, especially for complex, variable logic that differs from stable technical components like RPC or MQ.

In the second‑hand marketplace “Zhuanzhuan,” each item is unique, unlike mass‑produced new goods. This uniqueness makes abstraction and reuse especially challenging.

Design decisions must balance when to abstract: too early leads to unnecessary complexity, too late results in duplicated effort and high migration cost.

No Silver Bullet

Fred Brooks’ “No Silver Bullet” principle reminds us that complex problems lack simple solutions; the middle‑platform’s issues still require multi‑dimensional, systematic approaches.

Nevertheless, the goal of abstracting for reuse to improve efficiency remains valid.

Resource allocation in the team shows a stark contrast: the “basic services” line (product, user, tagging, etc.) is staffed by about 1.5–2 engineers, while the “order” line has 5–11 engineers, highlighting the impact of abstraction depth on staffing.

Thin vs. Thick Services

“Thin” services focus on high‑frequency, low‑variation business logic close to technology (e.g., DAO‑style data access), enabling easy reuse across many scenarios.

“Thick” services handle richer domain logic (orders, payments, marketing) that, while more reusable, involve frequent changes, higher staffing, and greater coordination overhead.

Choosing thin or thick depends on how stable the business scenario is and how much commonality can be abstracted without excessive future change.

Don’t Get Lost

The industry debates thick vs. thin middle platforms, but the ultimate purpose is to deliver technical value through efficiency, reliability, and competitive advantage.

Efficiently support business. Ensure continuous, stable production. Help build industry barriers (e.g., patents).

Technical work should focus on solving real business problems, using appropriate architectural styles without being dogmatic.

Conclusion

After three years in the middle‑platform team, the author summarizes lessons learned, acknowledges unresolved challenges, and looks forward to future improvements.

Author Tian Wei, Zhuanzhuan Middle‑Platform Engineer

References:

https://www.infoq.cn/profile/3CB3B1724F2E52/publish

https://mp.weixin.qq.com/s/MJd9vVzPH_5YftavWOkPXw

https://kimi.moonshot.cn/kimiplus-square