后端开发：抽象建模经典案例

0.引言

在互联网行业，软件工程师面对的产品需求大都是以具象的现实世界事物概念来描述的，遵循的是人类世界的自然语言，而软件世界里通行的则是机器语言，两者间跨度太大，需要一座桥梁来联通，抽象建模便是打造这座桥梁的关键。基于抽象建模，不断地去粗取精，从现实世界到业务模型，从业务模型到设计模型，最终完成现实世界到软件世界的转换。

事实上，服务端开发工程师在大部分工作时间里并不是在写代码，而是在抽象建模。工程师需将业务需求抽象成领域模型、模块、服务和系统，面向对象开发时需抽象出类和对象，面向过程开发时抽象出方法和函数。

某种意义上，软件的本质就是抽象，建模则是系统地实施抽象的过程。作为一种将事物形象化的有效手段，建模可将现实世界中的事物及事物之间的关系准确地表达出来。

---

1.抽象思维

抽象在中文里可作为动词，也可作为名词。作为动词的抽象是指一种行为，这种行为的结果，就是作为名词的抽象。百度百科对抽象的定义为：人们在实践的基础上，对于丰富的感性材料通过去粗取精、去伪存真、由此及彼、由表及里的加工制作，形成概念、判断、推理等思维形式，以反映事物的本质和规律的方法。

事实上，抽象作为一种高级思维形式，与日常生活关系密切，例如数字，人类初期并没有数字这一概念，原始人类或许能够理解三个苹果和三只鸭子，但不存在数字 “三” 这个概念，在他们的意识里，三个苹果和三只鸭子是没有任何联系的。当人类文明发展到一定阶段，发现了这两者之间存在的一种共性，即 “三”，于是就逐渐形成了数字这个概念。此后，人们就开始用数字对各类事物进行计数。

---

2.软件世界中的抽象

软件的本质就是抽象，在软件世界里，抽象无处不在，典型如命名抽象、分层抽象、原则抽象。

2.1 命名抽象

作为一名软件工程师，最令你头疼的事情是什么呢？是写代码，看别人的代码，需求评审，还是修 Bug？Quora 和 Ubuntu Forum 曾经针对这个问题进行过广泛地调研，结果显示， 最令软件工程师头疼的事情是命名，没错，就是命名！应用名、包名、类名、方法名、字段名、变量名等等。如果你不曾为命名苦思冥想、反复权衡，也许你还不能算是真正的软件工程师。

关于命名，Stack Overflow 的创始人 Joel Spolsky 曾言：“起一个好名字很难，但这是理所应当的，因为一个好名字需要把要义浓缩在一到两个词（Creating good names is hard, but it should be hard, because a great name captures essential meaning in just one or two words）。” 其实，这个浓缩的过程便是抽象的过程。

很多时候，业务代码的复杂，并非业务本身复杂，而是人为因素造成的，命名混乱就是最常见的因素。虽然不合理的命名并不影响需求的实现，但却加重了认知负荷，随着时间的推移，理解代码的成本会越来越高。同时，命名不合理本质上是抽象不合理，往往影响可复用性。

2.2 分层抽象

在软件开发中，经常会用到各种分层架构，如经典的三层模型（展现层、业务逻辑层、数据层）和 MVC （Model、View、Controller）模型。如图 1 所示为阿里广泛采用四层模型，它包括 View、Service、Manager、DAO 四部分，通过分层将数据访问、通用处理、业务逻辑、终