元数据驱动的业务表单定制中心 思想和实践介绍

1、业务开发中常见需求本质

尤其是在2B的系统中，表单功能会非常常见。

• 从一套被设计被定义的数据模型开始（业务对象）
• 编写基于业务对象的各类操作，附加以对应的业务逻辑
• 基于多参与角色、多场景的业务输入，在将已有的业务对象操作方法复杂化/定制化
• 基于产品设计，将业务对象、业务逻辑、功能差异化、个性化定制、授权等业务表现具象化，呈现为前端页面。
• （此为纵向呈现，2B业务中还常并行有横向流转的业务和需求）

作为优秀的“懒惰”程序员，工作一段时间后就会开始思考：好像诸多工作背后都有共性的本质，虽然做的业务一直都在变化，但从技术应用的本质和技术能力上来讲，没有很大的提升。属于既有经验和能力的重复应用。

“既然看到了规律，那该怎么个方式偷懒（提效）呢？”

好，将难以分析的大问题拆解成几个小问题来分析通用化的技术方案：

【DB层面】

• 一套表 支持 多样化的业务对象和业务操作的需求。（且还要一定程度的支持性能、检索、分析）
• 对于用惯了MySQL结构化数据结构设计的研发来说，这是一个难以想象的事情。
• 如果是那样，那整套数据就会变成几个大字符串了。But, Why not？Try！Maybe it’s a good starting.
  • 随着需要支持的能力不断丰富，会基于此不断的演化、优化方案。只是一套表是走不远的。
• （这里，用简单方案起步，需要了再复杂化。例如：细化抽象N个业务对象，每个抽象业务对象一套通用抽象表，每个具体业务对象是抽象对象的具象化/实例化。如此，可兼顾通用性和数据层面的复杂操作）

【业务操作+业务逻辑】

• 常规操作提供默认实现，模板化。并暴露对应对象事件，供异步联动。
• 常规逻辑提供默认组件，供选择搭配。通过配置控制、组合
• 个性操作和个性逻辑 提供预留扩展点，供代码/配置扩展实现
• 个性流转提供工作流组件能力，且工作流组件本身也是高度抽象可定制
• 个性查询提供SQL级/可视