一文搞懂架构顶层设计之业务建模

在软件开发的世界里，“建模”往往是被频繁提起，却又容易被忽视的环节。无论是需求分析、系统设计，还是最终的代码实现，建模都扮演着承上启下的关键角色。它不仅仅是画几张图，而是一种把复杂业务抽象成可理解、可实现结构的过程。本文将从建模的基本概念出发，梳理软件工程中的三类建模方式，探讨为什么建模始终是软件工程的难题，并结合业务建模的具体推导环节，帮助开发者更清晰地理解业务建模的价值与实践路径。

关注腾讯云开发者，一手技术干货提前解锁👇

7小时不间断直播，看腾讯最新黑科技，赢百份周边好礼！

01、何谓“建模”？

不同领域，比如数学、物理、金融、计算机（业务开发、算法、数据），都有“建模”这个词，表达的含义都不一样，但高度抽象来看，就是”现实世界“到”某1类学科世界“的一个映射。只有把某个现实问题，转化成某1类科学问题之后，才能解决。

• 数学建模 大学的“数学建模竞赛”，就是把某1类现实问题转换成某1类数学问题。这里的重点是转换，而不是解数学问题。
• 物理建模 现实问题 -> 物理模型，初高中物理经常学的“滑块在斜坡上，受力分析”之类，就是一个典型的物理模型。
• 计算机建模 （1）业务逻辑的建模 所有业务逻辑，最终都映射成3种代码结构：顺序、选择、循环。 无论哪种计算机高级语言，都是这3种结构。 （2）数据建模 现实世界中的所有不同种类数据（线性、树状、网状），最终都映射成DB中的一张张2维关系表。 （3）算法模型 LR，决策树，神经网络... ...

1.1 人类为什么需要“建模”？

“建模”本质是对现实世界的一种“简化”，人脑的脑容量有限，装不下、也处理不了完整的现实世界所有信息

“所有模型都是错的，但有些模型是有用的”

当我们说苹果是”红色“的时候，是错的，仔细看，红里面夹杂着其它颜色；

当我们说牛顿第二定律的时候，知道那是一个常速下的近似公式；

当我们说LR算法的时候，知道那是对某个业务场景，多个因素之间关系的一个近似表达；..

只要这些错误在一定的“误差”之内，就不影响我们的工作和生活，所以是“有用”，不是“正确”。

1.2 建模思想总结

从上面的各种例子可以总结出：

像乐高积木一样，零部件（构造块）是有限的，要能够被穷举； 语法就是构造块之间组合时要遵守的约束关系； 2者，无限组合，排列出来的玩具是无限的。

从自然语言 -> 计算机语言 -> 再到语言的各种抽象/封装，构造块越来越大，所能构造的事务越来越复杂。

02、软件工程中的3类建模

当需求和产品方案定了之后，接下来，理论上要经历3类建模（3个建模过程），才能完成从现实世界到计算机世界的映射。 下图展示了每个阶段要输出的产出物：

正如上一篇所说，不同公司/不同团队/不同业务选用了不同的软件工程流派，所以很少有团队严格遵循了上面3个建模过程：

• 业务建模 互联网公司的团队几乎没有，没有业务流程图的标准，也没有严格的系统用例，更没有系统用例规约
• 领域建模 随着DDD（领域驱动设计）方法论前几年在国内的火爆（这方法论早在2004年就有了），几乎所有开发人员都知道“领域建模“这个词，但又是仁者见仁、智者见智，对这个词的理解，很难达成共识。根源还是前一篇所说的，DDD缺乏标准化的表达形式，大家沟通的是”理念“，而不是对着”精确的图纸“讨论问题，自然各种信息Gap，”自说自话“。
• 数据建模 这个词的含义相对来说歧义最少，开发人员也最熟悉，大学计算机课班的《数据库原理》课程都会教授这个
• ER模型 数据库的第一、第二、第三范式。。。 DB的表设计、主键、外键...

03、建模是软件工程的难题

我们后面会详细谈架构，架构搞久了就会发现，架构里面最难啃的那块骨头就是“建模”。为什么这么讲？ 架构领域讨论的问题（这里主要指互联网公司的分布式/微服务架构）：

• 高并发、高可用、高可靠、高性能
• 安全
• 分布式事务
• ...

这些领域的知识偏“硬性知识”，知识体系主要还在“计算机学科”里面，答案相对客观，并且无论是公司内/公司外，相关的课程体系都已经比较成熟；

而建模是偏“软性知识”，建模的一半知识在“计算机学科”，另外一半知识在上篇说的“需求和产品“，也即对现实世界的认知、对语言的认知，因为”软性“，”活知识“，更难习得，需要不断实践 + 悟性。

接下来就对这个”软性知识“，从哲学视角进行一个解构，方便把握：

3.1 建模是业界难题 - 原因之1 - 来自语言学的思辨

无论是需求，还是建模，都是用自然语言表达的，这里从“哲学”角度来反思一下语言的特点：

• 自然语言的模糊性/歧义性

2000多年前，亚里士多德就在讨论“概念”如何定义的问题 - 通过“属加种差”法来定义一个个概念；

17世纪的荷兰哲学家斯宾罗莎，创立了《道德几何学》，希望用欧几里德几何学13卷本的思想来构建伦理学：即用几何学的形式化表达方法，来建构整个人类的伦理道德体系。为什么要这么干？因为基于自然语言表达的伦理体系太不严谨，歧义、漏洞。。。（额外想想：中国的孔子、道家，是用什么语言和表达形式在构建伦理学？）；

今天，人类世界定义了各式各样的法律，法律条文白纸黑字摆在那，但还是没用，需要出司法解释、司法解释还要再加司法解释，需要律师这个职业对各种法律条文进行解读，找其中歧义/漏洞的地方。。。

举这些例子是想说明：

如果站在”语言学“的角度来看，我们写的需求/产品文档/建模文档，必定到处是模糊、到处是歧义；

在这个基础上，想有严格的逻辑，是不可能的

例子1: 电商平台的“商品ID“

在电商平台中，几乎所有系统（商品/库存/价格/搜索/推荐/供应链/订单/支付/。。。）都会使用”商品ID“这个概念，但会发现，当我们要定义”什么叫一个商品”的时候，却很难，大家的理解差异很大

同1个东西，来自3个供应商（3个卖家），是3个商品，还是1个？

同1个东西，做了多个促销活动，在不同渠道售卖，是算多个商品，还是1个？

同1个东西，海淘/非海淘，算1个，还是多个？

同1个东西，跟不同供应商合作，用了不同业务模式，算1个，还是多个？

。。。

类似例子无穷，后面我们在深入讨论领域建模/数据建模时，进一步深入讨论这个话题

• 语言是思想的边界

传统上，我们对语言和思想的关系是这样看待的：语言是表达思想的工具（介质），先有思想，后有语言；

20世纪的哲学转向，即“语言哲学”，说：

语言 = 思想

不存在有思想不能表达，如果有某种思想表达不出来，那就是没有思想。

以这个理念来看软件工程的各个方法论，如果我们无法把1种建模方法论的思想/理念，用详细的语言（文字+图表/图例）精确表达的话，那可能意味着这个方法论并没有“思想”，只是“徒有其表”。

想象一下，如果要建造一个80层摩天大楼，没有详细精准的图纸，只有“概念图”/“草图”，施工怎么开展。

3.2 建模是业界难题 - 原因之2 - 现实世界本就无比复杂

此前有篇非常好的文章《理解业务系统的复杂性》，已经很好的论证了这个问题。

如果我们对“复杂性”没有心理预期，"too young too simple"，对“复杂性”没有足够的重视，很难做好建模。

现实世界的复杂性，超出任何一门学科的复杂性。

3.3 建模是业界难题 - 其它原因

1. 跨团队的信息壁垒、信息沟通障碍、信息失真 这个和管理学面对的问题一样，在一个大型组织，同样的信息/需求，经过多人转述、多人文档翻译，信息失真、误解，这个是常态
2. 意识问题 在用户、产品人员、运营人员眼中，沟通的语言是“流程”而不是“模型”。开发人员在与他们沟通过程中，慢慢就形成了以“流程”为主导，而不是以“模型”为主导的思维方式。这使得整个开发过程是“流程驱动”，而不是“模型驱动”。大家在讨论业务与系统解决方案的时候，大部分时间都花在了业务流程、业务规则上，而不是深刻挖掘流程背后的不变因素。
3. 迭代速度 再稳固的模型，也不可能一成不变，毕竟现实世界一直在变。当现实世界变化到模型不能支撑的时候，要能马上修改模型才行。但实际情况是，因为开发效率的原因，工期赶不上，然后就会在旧的模型上进行打补丁，补丁一个接着一个打，最后整个系统臃肿不堪，开发效率进一步降低，如此恶性循环。 这也是为什么互联网公司一直强调小步快跑、快速迭代的原因。既然现实世界变化太快，我们就不要仔细去研究建模了，反正变了可以快速迭代，快速修正。这种方法对于C端的产品线，业务流程不复杂、牵扯系统不多的情况很管用。但对于B端的大型企业项目，会牵扯到很多系统之间的对接，一次开发，实施完很久也不会再动的情况下，这种方法就不适用了。
4. 火候的掌握 领域模型是要对现实世界建模，既要去寻找不变性，又要为可能变化的地方留出扩展性。什么地方是不变的，要作为基础；什么地方是易变的，要留出扩展性，这其中并没有一个标准原则。另外，各家公司的业务规模、速度不一样，团队实施能力也不一样。所以在实践中，要么会“缺乏设计”，要么会“过渡设计”。对火候的掌握，需要有悟性。只有反复思考，反复推翻自己之前的想法，再重建新的想法，才能在实践中不断找到领域模型、业务发展速度、技术团队能力之间的“最佳平衡点”。

接下来详细剖析软件工程的3类建模

04、业务建模

业务建模的输出有4个：

• 业务用例
• 业务流程图
• 系统用例
• 系统用例规约

这4个东西之间，是有严格的逻辑推导关系的：

业务用例 -》业务流程图 -》系统用例 -》系统用例规约

在ToC的软件开发中，通常没有“业务建模”这个环节，产品经理输出的文档就带了详细的业务流程图 + UI原型。

为了让业务建模和领域建模不混淆，这里还是要详细讨论一下什么叫业务建模：

4.1 什么叫“标准的”业务流程图 ？

业务流程图，也叫业务序列图，产品经理天天画，开发/测试也天天画，大家不是都会吗？非也。

去搜索引擎里面输入“业务流程图”几个字，会发现画法五花八门，这里的“标准化”到底指什么?

• 业务流程图的每1条泳道对应什么？

在业务流程图中，每1条泳道要么是一个角色，要么是一个系统，不能是一个系统的内部模块。

在画业务流程图的时候，应该把每1个系统当作“黑盒”来看待；但很多时候，产品/开发在画业务流程图的时候，其实已经掺杂了太多系统内部的技术细节，那是“系统流程图”，不是业务流程图。

之所以会这样，我想一个原因是大公司分工拆的太细之后，1个系统被拆到了多个团队，导致产品/开发认为他负责的那个小模块就是一个系统。

这涉及到我们对“系统”如何定义的问题。

理论上，“系统”不是用他的实现技术来定义，而是用“纯粹的外部性”来定义，就是这个系统的职责边界，而不是物理边界（跟它是单体，还是分布式，没有必然关系）。但在大厂，一个系统被拆的太细落到多个团队之后，这个很难做到。

业务流程图与系统流程图的区别，总结如下：

• 标准化，主要指“内容”，不是“形式”

业务流程图，可以用“泳道图”来画，也可以用UML的“序列图”来画（类似开发画的系统时序图，虽然2者看起来长得很像，但内容上有本质区别）。

关键点还是上面说的，到底定义多少个泳道（参与者）。如果泳道个数定义的不对，形式再好看，也是违反了业务流程图的思想。

4.2 业务建模的研究对象不是系统

画业务流程图，思考的出发点不是“系统功能”，因为业务建模的研究对象不是一个IT系统，而是一家公司/一个组织，定义这个组织的“外部性”，即对外能提供什么价值。

比如ToB领域的“数字化转型”，就是要用数字化手段重新设计整个业务流程，这里重构的不光是系统，还有人。

站在业务建模角度，人和系统是等价的：

人是要休息、要发工资的系统

系统是24小时不休息的人

都是为了完成一个“价值点”的一个“零部件”，人与系统协作，产生协作流程，即业务流程。

一个业务用例 = 一个价值点。

一个业务流程 = 一个业务用例的实现过程（人与系统的协作过程）。

4.3 难点来了，到底谁是“用户”？

要定义“价值点”，先得定义，我们为“谁”提供价值？？？

=> 定义不了用户，

=> 也就定义不了“价值点”，

=> 也就定义不了“业务流程”

如果你做的是一个纯粹ToC的产品，用户很好定义，就是“C端用户“。

但随着商业化的增加，多了一类用户：商户；

业务再复杂，又会多了”某1类xxx用户“；

最后，难搞的就是：多类用户的利益是冲突的，到底优先服务谁，再服务谁，再再服务谁，这是公司的战略问题。

4.4 价值点“拆解“之后，价值被模糊了

除了不同用户的价值冲突之外，还有一个价值模糊/价值稀释的问题。

如下图所示：1个终端用户的“需求”，可能被产品经理拆分成了3个子需求，下发给了团队1，2，3 对于团队3来说，他的用户是谁？终端用户，还是团队2？

困境：他的需求，大部分都是团队2提的，他怎么知道这是终端用户的需求？

所以，这里有4个价值：

• 用户价值
• 公司价值
• 某个团队价值
• 个人价值

公司的管理，应该尽可能让这4个价值对齐。

4.5 区分业务用例与系统用例

业务用例：研究对象是一个组织，组织的一个价值点对应一个业务用例

系统用例：为了实现组织的价值，组织里的员工与很多个IT系统协作。每个系统，有一批系统用例。每一个系统用例对应这个系统能提供的一个价值点

无论业务用例，还是系统用例，都是从“价值点”出发来思考，不一样的是为”谁“提供价值点；

前者针对的是”组织“的用户，后者针对的是”系统“的用户，

只有先定义清楚到底谁是”用户“，才能定义”价值点“。

4.6 系统用例规约

光有系统用例还不够，太粗了，一个系统用例寥寥几个字，只是表达了系统提供的一个价值点，没有详细描述用户和系统之间为了完成这个”价值点“，经过了几个回合的交互，这就需要“系统用例规约”。

“系统用例规约”是每1个系统用例的详细描述，这个描述是结构化、形式化的（如下图所示，来自《软件方法》一书》，虽然是用自然语言描述，但遵循一定的规范。业界也有建模软件，比如EA（Enterpise Architect）支持系统用例规约的编写与管理。

因为这个在ToC互联网公司很少有团队用，此处略过，有兴趣的可以去参考业界资料。

至此，说清楚了什么叫“业务建模”，虽然ToC产品不遵循业务建模的方法，但学会画一个标准的业务流程图还是很有意义的，接下来的序列讨论领域建模。

领域建模是3个建模中最重要的部分，“业务建模”还可以划入需求分析（产品经理）的工作范畴，而领域建模将是“需求世界”和“计算机世界”映射的关键桥梁。

-End-

原创作者｜余春龙