概念

• 需求
• 领域
• 效率

关键词

什么样的业务才算复杂业务？

常用建模方式

• 宏观角度：实体关系模型
• 微观角度：业务流程图

通过分析UML的复杂度，可以大体评估出业务的复杂度量级

业务流程图复杂度估算

• 循环复杂度

实体关系图复杂度估算

• 实体数 * 实体复杂度系数
• 关联数 * 关联复杂度系数
• 相加

CRM状况：实体多，关联杂

项目驱动的技术升级

以往项目复杂度

以往项目时间周期

以往项目架构

新项目复杂度

新项目时间周期

保持架构 / 升级架构

思考路径🤔

简单粗暴的讲

• 任务大
• 时间紧

具体的讲

• 复杂度数量级级别提高
  • 实体个数30+
  • 实体间关联数100+
  • 粗略评估复杂度增长约10倍（相比绩效系统
• 项目时间有增加，但没有匹配复杂度的增加

效率跟不上了，技术需要升级了

新复杂度算法

• 原算法
  • 实体数 * 实体复杂度系数
  • 关联数 * 关联复杂度系数
  • 相加
• 技术升级，以降低复杂度系数
• 新算法
  • 实体数 * 降低后实体复杂度系数
  • 关联数 * 降低后关联复杂度系数
  • 技术升级成本
  • 相加

对技术提出的要求*

• 以可控的成本降低实体和实体关联的复杂度系数，要求技术不能过于复杂，要有渐进升级的能力
• 对于实体
  • 支持实体内部常规业务（CRUD）的快速搭建 ​
  • 字段行为可描述可配置，并支持实体内部特定字段的特殊呈现
  • 支持实体内部字段间的逻辑联动，以实现普遍的管理动作需求
• 实体关联
  • 实体关联可描述可配置
  • 实体对实体的引用要灵活
  • 支持实体间派生（通过实体A的实例，建立实体B新实例）

这里的技术升级属于“业务架构”？

• 切换技术架构对项目复杂度降低贡献往往是有限的，直接选用大家都熟悉的架构是最高效的。个人不提倡拿技术上的优势太间接对业务产生影响
• 业务架构则对复杂度降低影响有关键贡献，前提是项目的业务足够有特点，比如crm就很有特点
• 业务架构往往具有领域专用特质，可能不会那么通用，需要对具体业务具体分析
• 业务架构可能不会形成特别庞大的整体（相比技术架构），但往往有一些小的设计能产生很大的价值

前端社区的低代码实践

新瓶旧酒

各有理解，扔到知乎上又要吵起来了，但本质上

低代码平台

开发者的新“范式”

低代码core

非开发者的开发能力

提效降本的研发新产品/需求

GUI化

新产品

新需求

活动H5

调查表单

领域专用

可视化报表

整站（越来越少）

低代码平台是低代码内核的GUI化
达到降本提效的效果，趋势是领域专用

罗马不是一天建成的，从纯编码到低代码是有演化过程的。

领域演化举例（FORM

表单组件的硬编码组合

表单逻辑收口

表单组件的硬编码组合

传统方案

简单封装

配置驱动的表单组件

使用插件

配置驱动的表单组件

配置驱动

配置化&插件化

GUI

配置化&插件化

平台化

领域演化举例（FORM

领域示例

在低代码领域专用的背景下，在项目中划分适当的低代码领域是很重要的

低代码在CRM中的实践

在crm中，前端最适合做低代码的领域是FORM&LIST，绝大部分的实体内部业务&实体间关联也发生在此。低代码是crm技术升级的核心。

领域选择

当某领域的业务呈现重复且有固定抽象策略时，且开发者对领域有足够了解时，低代码建设便可以开始了

以form为例，从头到尾实现一个低代码架构，需要提前储备哪些信息？

• 陈列微观要素
• 规划宏观架构
• 归纳架构要点

FORM微观要素

• 插件
  • 插件生命周期
  • 插件交互事件
  • 插件选择&选项
  • 插件状态展示
  • ...
• 表单
  • 表单布局
  • 表单事件
  • 表单验证
  • 表单hooks
  • ...
• 元信息
  • 配置转换
  • ...
• ...

低代码插件化宏观架构

配置化&插件化在crm中是渐进式的，字段的形态都是从特殊到普遍的过程，等字段再从元信息层面支持。避免提前过度抽象。

配置化&插件化在crm中是分层使用的，可以直接使用插件，或者选择性的不使用元信息。

FORM&LIST在crm中是交互收口的，以FORM为例对于用户对所有字段的变更（onChange）交互（onInteract），都可以通过单个回调把控，使逻辑内聚

FORM&LIST在crm中形成了一个最小模版，实现了基础的CRUD，通过copy最小模版并进行二次开发可快速实现新的业务

低代码插件化架构要点

使用（1）：配置驱动

使用（2）：插件实现

使用（3）：集成元信息&权限&hooks

使用（4）：定制插件配置

通过修改插件配置，可以实现表单内部字段逻辑联动，面对类似需求，采用相似的形式即可

使用（5）：实体关联

通过元信息中字段的配置，描述了这个字段是用来做实体间关联的。前端将元信息配置翻译成插件配置，实现渲染。

一个完善的低代码方案基本满足了之前总结的所有要求

回顾一下对新业务架构的要求*

• 以可控的成本降低实体和实体关联的复杂度系数
• 对于实体
  • 支持实体内部常规业务（CRUD）的快速搭建 ​
  • 字段行为可描述可配置，并支持实体内部特定字段的特殊呈现
  • 支持实体内部字段间的逻辑联动，以实现普遍的管理动作需求
• 实体关联
  • 实体关联可描述可配置
  • 实体对实体的引用要灵活
  • 支持实体间派生（通过实体A的实例，建立实体B新实例）

上面太抽象？具体来讲价值体现*

• 通过元信息&权限的配置，无需开发即可实现一些通用需求：
  • FORM&LIST中的字段，无痛增减字段，可制定样式，校验规则
  • 无特殊展示的流程，配置即可直接上线
  • ...
• 通过低代码开发“范式”，可以快速实现一些特殊需求：
  • ​表单内部联动
  • 表单字段特殊字段校验
  • ...
• 良好的渐进式使特殊需求通用化成为可能

距离GUI化还有多远？

• 元信息编辑GUI
• hook编程GUI
• ...（不算太远，但没必要）

GUI化关键组件🤔

EDITOR

结构化数据+存储

DSL

RUNTIME lib

GUI其他服务

PARSER

GUI低代码平台

（产物：DSL）

RUNTIME

不是绝对的

EDITOR

结构化数据+存储

DSL

COMPILE lib

RUNTIME lib

GUI其他服务

PARSER

GUI低代码平台
（产物：结构化数据）

RUNTIME

CI/CD/其他编译服务
（产物：运行时代码）

其他优秀实践

（1）依赖单一结合依赖倒置

单一依赖

业务组件的依赖要尽可能简单，在crm中大部分业务组件仅依赖其业务store，单一依赖原则满足实体间的灵活引用，实体间派生更简单

依赖倒置

通用的业务组件不适配任何业务员store，仅对业务store提出需求，业务store需自行实现interface，以适配业务组件

业务store

提取参数

业务store

通用业务组件

通用业务组件

其实传统的业务组件也未尝不是依赖倒置，只不过中间透一层，在某种场景下不必要

在crm中无需提取参数，直接让store满足interface即可，改动不大，但量变产生质变。贯穿整个crm的开发，收益不小。

单一依赖结合依赖倒置

示例1：通用组件导出

示例2：业务特定组件

特殊到普遍的渐进式抽象在这里仍然适用，不是所有的通用组件一开始都是通用组件，Avoid Hasty Abstractions。先实现的单一依赖，后来发现普遍性很好再做依赖倒置。

其他优秀实践

（2）可描述的模块间副作用

当线索被创建的时候，除了对线索本身产生影响，在服务端， 也有可能对其他模块产生了副作用 ，前端需要对所有副作用有所响应。常规方案中，需要显式的调用一些刷新回调来展示副作用后的最新数据。不过在crm系统越来越复杂之后，发现这种方式有很大的缺点：

• 非常繁琐，可能透传过多，维护成本很大
• 无法清晰 描述模块间的副作用关系

一个实例则是一个图状网络的单点，在具体业务中，我们需要描述：

1. 它需要响应模块的副作用（上图的出边，比如B，是[B, C]）
2. 它会对哪些模块产生副作用（上图的入边，比如B，是[A, B]）

对于上面的模块B，需要先描述对A，B副作用的响应：

以及对于自己的副作用，哪些模块需要响应：

这样B的入边和出边就描述好了，看看运行时的case：

• A模块更新，因为A可能影响[A, B, C]模块的数据，B可能受[A, B]的写入副作用影响，两者有交集，说明影响成立，执行影响回调

• 需求
  • 实际业务需求驱动技术升级不盲目造轮子
• 领域
  • 选择合适领域，调研社区内领域方案，把握领域微观宏观情况，归纳设计要点
• 效率
  • 平衡技术升级成本与效率提升的关系，拥抱渐进式不求大而全

关键词回顾

讨论时间