业务逻辑的灵魂在哪里？

随着大数据的发展，数据建模、模型比赛、模型分享概念纷纷如约而至，各类真真假假的模型纷纷登场亮相，周边朋友也经常讨论模型的灵魂所在，而业务逻辑却甚少被人提起，究其原因，可能是大家都是业务领域的专家精英，认为业务逻辑就是业务规则，业务规则就是业务，如果你也这么想，那可能就要出问题了。

业务逻辑、业务规则和具体的业务，这是三个完全不同的范畴，我认可也相信你非常熟悉你的业务，但是，我不太相信有太多的人会明白业务背后的业务逻辑，因为一旦你明白了业务逻辑，一个基本合格的模型基本就在你手中了，但是很可惜的是，迄今我们没有看到太多成功的，有示范意义的模型。所以，可以聊聊业务逻辑这个事。

看一下这个概念，业务你可以看成是一种服务，既然是服务，那就会有服务与被服务对象这两个实体，业务规则就是这两类实体在互动中必须遵守的准则或遵循的流程，而业务逻辑是在完成所有同类业务中总结提炼出的一种规律，俗称“套路”。

IT 精英都会明白一件事，你要想做一个好的需求分析师，一个不错的架构师，你最大的本钱一定是掌握了这个领域更多、更细的业务逻辑。设计模型的根本原理其实跟设计一个系统差不多，或者我可以这么说，在某种意义上，一个模型就是一个小的应用系统，因此，软件设计架构的通用三个层级完全适用于模型的构建，这三个层级是就是展示层、业务逻辑层和数据层，其中展示层负责模型的外在界面以及与用户的交互，逻辑层就是今天说的重点，用户把自己的请求交付给逻辑层，经过逻辑层判断，把请求按照既定的组织次序提交给数据层，按照一定的策略再向等待在展示层的用户返回结果。这就是一个模型运行的经典场景。因此，我们可以看出，业务逻辑其实就是一个处于承上启下位置的“中间件”，它至少涵盖了四个部分：业务实体、业务规则、数据治理、运作流程。

我们用“群租房”举例说明这个问题。“群租房”（简单讲，就是一大堆人住在一个不应该住一堆人的家里，为啥要管这个我就不多说了，想想一屋子人的传销吧）管理的其中一个业务逻辑为例，这个例子就是通过用水量发现群租房的业务模型。

这个业务模型涉及的业务实体包括出租（家庭）户、多个实际居住人、社区民警、每户用水量数据等。业务规则是社区民警通过对全小区每户用水量的比较，把超过平均用水量一倍以上的房子找出来，因为用水量大很有可能这些房子里住的人多，因此这些疑似是群租房。如南方一个四口之家大约一个月用 10 吨水，那就把用超过用水 20 吨以上的房子挑出来，当然，这个与所处的地理位置，所处的季节，不同的小区等诸多因素有关。

接下来的数据组织、数据调用、数据质量保证，除了用水量的数据，还有户籍数据，地理信息数据，屋主数据等等，其中数据质量问题在此还要多说一句，如用水量数据从自来水公司要过来，如何与户籍数据对接上，还有一大堆的清洗去重去噪转化对标工作，对这项工作要有充分的繁重的数据清洗过程的认识。然后就是设计业务逻辑的业务流，这是从社区民警工作的角度出发，从具体业务操作的角度看问题，工作流是业务逻辑的一部分，它的作用是定义和约束实体之间的交互关系，但不涉及规则的制定，更不涉及数据的处理和质量保证等方面。

在这个案例中，业务流主要就是社区民警在应用时输入什么条件，到最终的结果数据如何到社区民警手上的一个完整过程，一般都能用图示的方式把开展的具体流程展示出来。最后是核心部分业务逻辑的作用，它负责模型领域内的业务数据的处理，均是对具备逻辑性数据的处理，如生成、处理及转换等。同时对所输入的逻辑性数据的正确性及有效性负责。通俗地讲，就是能用“计算公式”这种方式表达出来，如这个案例，计算公式就包括计算全小区各户用水量的平均数，超过一倍的数值计算，以及与户号与户数对应等。

模型的业务逻辑与系统建设的“业务逻辑层”有很大的相似度，但也有一定区别，业务逻辑是应用模型的核心和灵魂。严格讲，一个模型除界面和人机交互设定外，其余都可看作是广义范畴上的业务逻辑，其实业务逻辑说到底就是如何处理数据的逻辑。