我写《前端数据治理之道》围绕一个中心词汇：业务。但我在一些文章的评论中收到“业务交给后端去处理，前端做展示就好了”类似如此的思想。这类思想我个人的理解，更多是站在后端开发者的角度看问题，因此，我打算写一篇文章，专门讨论什么是业务逻辑。

很明显，在部分场景下，前端是不可能只做展示的，随着B端、G端产品的强势，这种“前端只做展示”的应用架构已经不符合需求了。我观察到，业务在开发层面有两种存在形式：数据的业务，人机交互的业务。站在后端开发的角度，只看到第一种，但在实际开发中，前端开发需要兼顾两种业务，而且，很大程度上后一种需要以前一种为基础。

数据的业务由持久化数据和逻辑代码构成，基于这两个基础，可能还需要搭配各种系统来实现，例如需要消息通知系统来在每一个业务节点上推送催办消息给特定用户，例如需要利用定时任务系统来拉取第三方数据，例如需要队列服务来解决长串任务堆叠。总之，我们传统的后端系统基本上只关注这一层面的业务。

在前端，基于数据的业务也同样存在，举个例子，我们做了一套数据视图系统，对于用户而言，他们可以通过挑选几个字段的所有数据进行统计，并为了研究不同因子变化带来的结果变化，直接修改某些值来进行计算结果。很显然，这里用户进行的这些操作不会对线上数据库产生任何影响，因此也就不需要向后端提交数据。这些数据被存在客户端内存中，一旦用户离开这个界面，这些临时数据就可以销毁。如果按传统做法，前端必须将一大堆数据post到后端接口，由接口返回计算结果，然后再由前端来渲染。但是很明显，相同的计算在前后端执行得到的结果是一样的，而传统方式还要付出网络交互和前后端耦合的代价，而这类计算仅仅当前这个用户用到一次，不需要持久化，交给后端处理，还要让后端考虑性能、并发等风险。可见，这一业务虽然是数据业务，却可以在前端完成。

交互的业务是本专栏要关注的重点。人机交互大发展是当代计算机系统发展的重要一面，如果只重视数据业务而不关注人机交互，那么丑陋的命令行模式就可以完成大部分计算任务。但是如所有人所见，如今的业务系统需要用户在一个界面，结合界面上呈现的多维信息，完成不止一个操作。而且为了提升用户体验，产品设计人员想尽一切办法，让用户明晰每一个操作的作用，避免做了错误操作。现代应用的交互复杂度，以及交互后面所蕴含的业务逻辑，有时，让人望而生畏。

业务的逻辑，表面上可以用一大堆if…else来概括，但实际上除了判断之外，它还可能涉及形式。

很多人对“形式”这个词不敏感，但如果你研究过形而上学或符号学，就会不再那么轻松。形式在交互中极为重要，我们用一个具体的场景来解释。

现在有一个表单，里面有一个输入框，该输入框对应的字段，需要关联到系统中已有的某个对象，但也有可能用户不选择关联，使用输入的值作为结果。而如何用户选择使用输入的值作为结果，那么就有可能输入一个系统中已经存在的对象，而该字段的规则是不允许系统中有重复值。在这个场景中，是暂时没有数据参与的，也就是说，它的整个业务必须依靠前端来实现。

除了单点的复杂交互业务之外，还有连续的流程交互业务。以一个审批流为例，一个审批单发起、审批A、审批B、结项，这个流程环节必须走。暂不考虑流程分支流问题，后端自有后端的方式交互这一审批流管理起来，现在我要问的是，前端做了什么来合理管理流程业务？是只展示后端输出的内容，还是自己构建了一套流程模型？

现在我们再来看看什么是业务逻辑。

实际上，我们口口声声的业务逻辑，是只用代码实现的真实业务的规则映射。注意“规则”这个词，简单说，一个业务中，存在什么逻辑，可以通过在纸上画出不同业务对象之间的联系和约束，并将这些联系和约束一条条列出来，形成一个列表，而这列表中的每一条，就是一条规则，这些规则的总和，就是这个业务的业务逻辑，而且是全部业务逻辑，你不能再多列出一条了。

既然是一条条的规则，那么我们就可以在代码层面对规则进行管理。对于前端开发者来说，最熟悉的规则管理，莫过于路由管理。现在，我们做一个思想实验，将每一个route对应一条业务规则，每一个url对应某一时刻后端接口输出的业务数据，随着后端接口业务数据的变化，不同的业务规则会被使用，而没有匹配到的规则会被屏蔽，从而，在界面上呈现出根据业务逻辑而提供对应的人机交互的效果。

由于规则是有限的，我们可以借鉴有限状态机的开发范式来实现对业务逻辑的开发。有限状态机，很好的为我们提供了在不同规则之间转换的一种思路。当业务从一个状态切换到另一个状态时，可以很清晰的获取当前状态，以及下一步我可以做什么。业务切换也是这样，我们明确当前可以做什么，也知道下一步可以做什么，到具体要做什么，要看用户做了什么操作。

但和有限状态机不同，业务流转并不是状态切换，每一次流转，都可能牵涉一堆东西，例如从一个阶段进入下一个阶段，参与业务的业务对象变了，我讲过，业务流程是实体的进出和状态变化的总和，所以单纯靠有限状态机是解决不了的，但我们可以借鉴状态机切换状态的这个切换编程模式。

由于我并没有将所描述的这套东西实现成框架或库，所以无法再具体到细节处。

最后，前端处理业务逻辑不仅不是多余，而是当下复杂应用的趋势和要求。目前而言，前端领域还没有强大的针对这个领域的库或框架，因此，需要我们积极探索，重拾软件设计的技术体系，寻找更多可能性。