简单场景

image.png

左侧是一个列表，列表的单项点击编辑按钮，右侧表单则显示对应数据。

之前的设计方式

按照业务区域来完成业务组件的划分，并且将各个业务区域的逻辑埋在对应的业务组件中。

同时重度依赖mobx强大的数据监听能力，将操作数据的业务逻辑和数据实体集中在一起。

该页面组件的整体结构可能如下：

image (1).png

在这样的业务组件结构设计下，页面的数据流向及处理流程如下图：

image (2).png

问题点

数据流向

1. 始终从数据实体开始，经过各个组件，最终回流至数据实体中，导致一份数据在不同的组件中留存。
2. 数据大部分时候是双向流动，子组件将数据处理为业务数据状态返回给父级，就会导致数据流向复杂且不可控。

数据处理流程

1. 如果数据是未经业务逻辑处理的原始数据，就会导致所有途经的组件内部都必须增加业务逻辑处理成为业务组件。
2. 对于关键业务节点的组件，需要衔接上下游组件，就会导致关键组件必须处理上下游业务流程。
3. 处理流程中观测的数据很可能是数据实体中同一个可观测数据，就会导致处理流程可能会被其他改变所影响。

耦合

1. 各层级的组件与业务逻辑非常耦合，即便分拆，也只会得到一个只适用于某个特定业务流程的UI组件，无法真正通用。
2. 在关键业务节点需要衔接上下游组件，就会导致不同组件间业务性耦合增加，使用一个必须一齐使用。
3. 由于各个组件的行为与业务关联较深，就会导致页面行为和交互较固定，在面对页面交互修改时，只能修改所有组件行为和交互。

协作

1. 整个流程需要各个组件开发期间紧密配合，就会导致新的团队成员介入开发时，完全无法快速理清关系。
2. 组件与数据实体之间的对应关系很隐秘，一个数据实体可能在多个组件中有对应关系，就会导致新的修改会影响到其他组件。
3. 业务逻辑散落在各个地方，可能独自成一个文件，也可能在相关行为的组件中，就会导致需求修改时，各个地方都要完成修改。

如何拆解

基于重业务组件轻UI组件的策略进行拆解。

重业务组件

将业务处理的流程完全集中在某一个层级的组件当中，尽可能将一个业务领域的流程在一个组件内实现。

通过对外暴露业务能力开放自身的数据处理流程，例如数据调用能力、业务逻辑能力等。

封闭自己的渲染方法，例如渲染时的数据状态、渲染的内容、渲染的模版等。

封闭自己的数据流向，例如向子组件传递数据、向子组件传递回调方法等。

轻UI组件

将非业务处理流程的组件完全抽离业务

通过对外暴露触发事件开放自身的UI能力，例如UI行为事件、UI交互事件等。

封闭自己的渲染方法，例如渲染时的数据状态、渲染的内容、渲染的模版等。

重设计

按照如上思想重新设计刚才的案例

该页面组件的整体结构如下：

image (3).png

在这样的业务组件结构设计下，页面的数据流向及处理流程如下图：

image (4).png

特点

数据流向

1. 在业务组件中使用内部的数据状态作为唯一数据实体。
2. 数据流向为单向流动，业务组件间不流动数据。

数据处理流程

1. 业务逻辑完全集中于业务组件内部。
2. 通过业务组件对外暴露的业务能力，从而对外开放数据处理的流程。

耦合

1. UI组件无业务逻辑，仅处理渲染相关流程，与业务流程完全解耦。
2. 业务组件通过暴露能力在业务入口的页面组件中耦合，减轻耦合程度，将耦合封闭在业务范围内。
3. 业务组件仅关注业务领域，通过调用不同UI组件的UI能力完成业务行为的实现，让业务流程与UI行为解耦。

协作

1. 一个业务流程可以在同层级的业务组件中完整体现，方便接手的团队成员梳理。
2. 业务处理逻辑集中在业务组件层，不会散落各处难以查找。

总结

每个业务领域都有自己的业务流程模型，但不能因为业务流程模型的复杂，就放弃拆分，甚至将复杂的业务流程塞入普通的组件中。

业务需求或实现虽然复杂多变，但对于企业级的业务系统来说，业务流程或者业务模型是固定的，迅速找到以不变应万变之法才是唯一的破局之路

这套重业务轻UI的策略其实就是，将业务逻辑结合单一的UI能力整合后，转换为强大的业务能力来提升的多变性，从而达到可以快速支持多变的业务需求。