【软件工程底层逻辑系列】建模的底层逻辑

简介: 在本文中,给出建模的底层逻辑:用图形逻辑地表达现实业务的抽象,通过一些大家通识的技术案例讲述建模的过程。

建模对于大家来讲并不陌生,而且建模的方法也有很多,如用例建模、四色建模、事件风暴等,但在日常工作中,大家又觉得建模挺虚的:怎么把建模落到实际开发工作中。个人认为建模是分两部分:第一部分是业务概念建模,对现实业务抽取核心概念构建出模型(知识层);第二部分是系统建模,系统建模是源于业务概念模型,遵循某些原则最终形成开发可落地的模型(操作层)。在本文中,给出建模的底层逻辑:用图形逻辑地表达现实业务的抽象,通过一些大家通识的技术案例讲述建模的过程。


一、建模的底层逻辑

建模的作用不言而喻,它可以极大简化大家对复杂事物的认识,让人能在短时间内有全局视野看清楚业务,而且建模是用面向对象的思维分析事物,也容易转化成类图。用一个公式表达建模的底层逻辑:建模 = 图形 + 逻辑 + 现实的抽象,用一句概括即是用图形逻辑地表达现实业务的抽象,接下面主要讲述图形、逻辑、现实的抽象这三部分的内容。

1.1 图形

图形即为UML图形,下面是6种对象间的关联图形,在建模中尽量遵循UML标准画图,方便大家理解。

  • 继承:子类继承父类的特性,有的语言仅支持单继承。
  • 实现:子类实现父类定义的接口。
  • 组合:一个类包含另外的类,但它强调的是一种强关联关系。
  • 聚合:也是表达一个类包含另外的类,但它的关联关系比组合要弱。
  • 关联:通过一个类可以关联到另外一个类,可分为单向关联和双向关联,一般以类的成员变量体现。
  • 依赖:比较弱的一类关联关系,一般是以接口参数的形式体现。

image.png

1.2 现实的抽象

我们的现实业务有的是非常复杂的,如果涉及到专业领域概念,新手想入门是挺难的,当我们不清楚业务链路和逻辑时,直接看代码实现时很难有全局的视野,不能够串起全局业务间的内在联系。

当我们切入到一个新领域中,并非短时间内就要成为该领域的专家,急需一种方法用20%的时间能够掌握该领域80%的业务知识,一个可行的方法就是建模,通过对现实业务进行抽象,构建出全局业务概念模型,有了全局的认识,再去了解业务细节就会快得多。模型好比地图,先做到心中有谱,再"按图索骥",我们比较迷茫时,往往是看不到全局的"地图",因此也就做不到心中有谱。

我们要建模的对象即是问题域,我们并不需要覆盖所有的点,而是基于核心的内容进行建模,Eric Evans 在建模书中提到一个观点:建模是出于某种目的而概括地反映现实,这里的概括就是抓住核心的意思。

现实的抽象有三层意思:一类是直接映射,比如现实有一个杯子,那么我们的模型中就有一个杯子;另一类是往上抽象一层映射,比如我们的组织中有一级结构、二级结构、三级结构等,那我们可以抽象成组合结构,形成父子节点的结构,这种抽象就更灵活了;最后一类是隐性抽象,前面两类抽象比较容易做到,最难的是隐性概念抽象,它很大可能是之前不存在的,需要新造出一个概念,就像软件设计中,通过新增加一层来实现解耦一样,通过新造的概念串联元素间的内在关联关系,如下面示例的中的"债权"概念。

举一个金融理财的案例,需要将投资的钱给到借款人那里,然后借款人还款时将还款给到投资人,当投资人的钱给到借款人时,就产生了债权关系,因此有一个债权的概念,这记录了投资人与借款人间的债务关系,债权就是一个桥梁。当借款还款时,对应的债权就会减少,当投资周期到了,债权就会进行债权转让,转到下一个投资人身上,当前的债权关系就结束了,下图虽然比较简单,但对理解系统至关重要。

image.png

1.3 逻辑

逻辑即为因果,也即元素之间存在某种关系,如果两个完全没有关系的元素放在一些,就会显得前因不达后果、风马牛不相及,让人不好理解。那么对应到建模上,我们的模型应该是非常具有逻辑性的,从模型上能看出业务核心要素,要素与要素之间的关系是怎样的。

逻辑主要体现在时空两个维度上:时间维度,一件事情节点完成之后,会影响后续的事情节点;空间维度,更多的体现在结构上,我们常说的空间结构就是这个意思。以时间维度为例,在电商结算中,当订单支付成功后,结算收单,收单后接受到放款的执行指令,在放款之前需要计算出放款明细信息,如卖家应收到多少钱、公司应收到多少佣金等,最后是打款转账,这个过程就是按照时间节点不断往后驱动,可抽象出如下图的模型。

image.png

空间维度即是结构关系,比如下图中的组织结构,像这样的结构类型,我们还可以找到更多的实际案例,比如交易订单有主子订单结构,执行单包含多个执行明细信息,模型最终呈现出来的就是一个结构,从结构维度也可以将其分解出更小的粒度。

image.png

不管哪种建模的方法,最根本的还是体现出了建模的逻辑性,用例建模的逻辑性体现在能够清晰地定义出用例场景,把所需要做的事讲清楚;四色建模通过人、事、物、时间、地点维度描述清楚一件事;事件风暴通过时间轴勾画出核心关键的事件。当我们构建不出模型时,并不是我们缺少建模的方法,而是建模的逻辑性上有问题,建模缺的不是方法而是经验和实践。我们不能神化建模,建模是很纯粹的,就是为了简化对复杂事物的认识,并且模型能够映射到实际开发的模型中。


二、建模的方法

建模的方法有很多种,方法多并不意味着建模的难度会很低,相反建模的门槛很高,对抽象思维要求非常高,而且建模并没有标准的答案,因此很多人觉得没啥意思。其实这里面有两部分:一部分是源于业务概念的抽象,它需要对业务的理解和抽象,往往大家在这一部分觉得没啥意思;另一部分是在业务概念模型的基础上,结合设计原则,最终设计出合理的系统模型,这部分是考验大家的设计功底。下面列举2种实践中常用的方法,这些方法并非是新的方法,是在日常工作中不断总结、实践出来的,具有更便捷实用性。

2.1 定义法

定义法建模的核心思想是通过简洁的一句话描述事物,然后根据定义进行建模,虽然方法听起来很简单,但真正用熟还需要大量的实践。

2.1.1 命令设计模式建模

命令模型在23种模式中,相对还有点复杂的模式,有一句话描述命令设计模型:A下达了命令,B接受到命令后按要求执行。将A抽象成命令发起者,B抽象成命令接受者,因此很容易找出有三个对象:命令发起者、命令接收者、命令。接下来就分析这三个对象间的关系:

  • 命令发起者与命令的关联:命令是命令发起者发起的,因此命令发起者是要感知到命令的,具体地表现就是命令发起者是要包含命令的。
  • 命令接收者与命令的关系:命令接收者是具体执行命令的对象,到底是命令接收者关系命令,还是命令关联命令接收者呢?这个可以看谁变化的可能性比较大,应该用稳定的对象包含易变的对象,根据现实经验,命令相对稳定,而命令接收者是易变的,比如做菜,今天是张三做,明天可能就换成了李四了。
  • 命令发起者与命令接收者的关系:它们之间是不会产生直接有关联的,是通过命令进行解耦的,命令发起者定义做什么,命令接收者完成具体的工作。

最终命令设计模式的概念模型如下图所示。

image.png

2.1.2 导航栏建模

店铺导航栏平时大家在浏览店铺时常遇见,可以点击不同的导航Tab看到不同的商品,比如新品、爆品等。用一句话描述导航栏:导航栏是由若干个导航Tab组成,点击导航Tab渲染出对应的页面。很容易分析出有两个对象:导航栏、导航栏Tab,但在导航栏Tab中还隐含了另外一个对象:导航栏Tab规格信息,这个规格信息描述了Tab的颜色、排序、跳转链路等信息,因此我们可以很容易画出导航栏的概念模型图。

image.png

很可能有些人觉得这个例子太简单了,如果你按照这种思路分析业务对象,是有别于传统面向过程分析的,比如导航Tab该不该展示是由它自己负责的,并不是在一个大的方法里控制的。

2.2 因果法

因果法的本质同事件风暴建模一样的,在用熟的基础上按照自己的习惯进行运用,不管什么方法,只有内化成自己的方法才有用。它的核心是基于一个对象不断往前和往后找因果关联对象,最终构建出完整的业务概念模型。

2.2.1 Spring容器建模

Spring IOC容器对大家并不陌生,以这个案例描述因果建模的方法。首先Spring IOC是一个工厂,因此有一个BeanFactory对象,同时它会包含业务Bean对象,因此最简单的一个Spring IOC 概念模型如下图所示。

image.png

接下来就需要不断追溯了,Bean是怎么到Bean工厂中的呢?应该有一个Bean注册器,在上图的基础上,再完善下。

image.png

再想这个Bean是怎么来的呢?即哪些业务对象会标识成要放到Bean工厂中的,会有一个扫描器扫描业务对象,发现有标识@Componet、@Service等注解的类需要放到Bean工厂中,因此这里面就会有三个对象:BeanDefinitionReader、BeanDefinition、BeanDefinitionRegistry,迭代后的Spring IOC概念模型如下图所示。

image.png

虽然这是一个简陋的Spring IOC概念模型图,但它还是把Spring IOC核心包含的对象展示出来了,结合现实需求,我们还可以加一些对象进来,比如考虑扩展性,会有BeanFactoryPostProcessor等。这里仅仅是一个业务概念模型,具体到系统模型需要结合设计原则来设计,如Bean工厂在实际中会拆分成多级Bean工厂继承的关系。


三、建模案例

根据第二节中讲的方法,下面通过三个技术案例描述在实际学习中的运用,通过模型可以快速让我们理解技术涉及的原理,当我们有了基础理解后,再去看技术框架源码时也会快得多。

3.1 异步事件建模

异步事件对于开发来讲并不陌生,将事件定义与事件执行进行解耦,用一句话描述异步事件:事件发布者发布一件事件后,经由事件分发器分发后,找到对应的事件监听器处理。这里面就包含了四个对象:事件发布者、事件分发器、事件监听器、事件。

事件发布者是将事件发布到事件分发器上,因此事件发布者是需要关联事件和事件分发器;事件分发器通过事件类型匹配,匹配上事件后调用对应的事件监听器进行处理,因此事件分发器包含了多个事件监听器。异步事件的概念模型图如下图所示。

image.png

在Spring事件广播器中,有添加事件监听器,以及通过事件查找到对应的事件监听器进行处理。

image.png

3.2 切面建模

切面编程在实际工作中应用得也比较多,比如在服务上增加横切功能,如日志打印、方法耗时统计等,接下来用因果建模法对切面进行建模。最开始有一个目标对象,即为我们要增加横切功能的对象,那么怎么表达这个横切功能呢?至少要包含三种信息:谁需要被增强?;增强的逻辑是什么?;什么时候增强?,描述谁需要被增强的对象抽象成切点。增强的时间节点抽象成通知。因此可得出初步的模型。

image.png

目标对象与切面是怎么关联上来的,相当于在目标对象的方法前后要额外增加一段逻辑,可以通过代理来实现,因此有一个代理对象,它会链接目标对象和切面,最终切面业务概念模型如下图所示。

image.png

当熟悉了切面业务概念模型后,再去看Spring AOP的源码会容易些,模型就是简化认识,提炼出核心关键的事物要素。

image.png

3.3 ORM框架建模

ORM是将传统SQL映射到对象上,更符合面向对象的习惯。同样我们使用因果建模的方法,ORM框架在底层最终还是要执行具体的SQL,因此将SQL语句抽象成Mapper,数据库配置信息抽象成配置信息,有了这两个配置信息,自然有对应的解析配置的类,初步的模型如下。

image.png

将执行SQL的过程抽象成会话,会话会执行SQL,将执行SQL的对象抽象成SQL执行器,在SQL执行过程中,需要做两件事:一件是参数解析;另一件是结果解析。最终的ORM框架概念模型如下图所示。

image.png

在执行器中,我们可以看到有配置信息、参数信息。

image.png

四、建模经验总结

4.1 能清晰地描述事物建模就成功了一半

建模是将混沌的事物抽象成有序关联事物的过程,混沌到有序,因此我们需要梳理清楚事物间的关联关系,如果我们都不能够清晰地描述事物,是很难建模的。不能够描述清楚事物,说明我们自己都还没有理清内在的关联关系,也就做不到抽象出有序的模型。

在日常工作中,可以尝试用几句描述一件事,看大家能不能理解到。在学校老师经常让我们概括文章的中心思想,就是锻炼这种建模能力,通过几句话把文章的核心内容勾画出来。我们在软件建模也是一样的,通过几句话把业务的涉众、业务结构、业务目标、核心关注点表达出来,然后通过业务概念模型呈现出来。

4.2 通过描述事物的结构是建模常用的方法

模型最终呈现出来的是一个图,这个图往往是有清晰的结构,比如房屋模型,它就有自己的结构:坐北朝南,有大厅、睡房、厨房、洗手间等,软件模型也是一样的,在2.1.2节中举了一个店铺导航栏的例子,如下图所示,当我们看到店铺导航栏时,可以想像下它是怎样的结构。

image.png

在实际的业务中,有两类模型:一类是偏结构型的模型;另一类偏行为型的模型,从个人接触到的业务看,结构型的模型偏多,比如订单有主子订单模型。我们也可以尝试从结构的角度去定义事物。

4.3 建模要区分知识层和操作层

模型一般有两层:一层是知识层;另一层是操作层,知识层中包含的概念是通识的概念,往往是面向使用者,比如我们在使用AOP切面编程时,可以用@Aspect、@PonitCut、@Before等注解时,它们就是属于知识层,知识层的内容抽象层次比较高,大家比较容易理解,我们所做的业务运营工作台也是做的知识层的内容,比如配置页面模板、站点配置等,这些可枚举的维度都是知识层。

另一层是操作层,操作层是支撑知识层的,还是AOP为例,底层有对注解的解析、动态代理的生成等;再比如Spring IOC中,有各类Bean的注解,在操作层中,有BeanDefinition的加载、识别、解析、Bean实例化、Bean初始化等,操作层中的实现也并非面向过程的设计思维,它也包含了抽象设计和遵循某些设计原则,这一点在下一节中会专门讲到,同样的设计,张三和李四可能不一样,正所谓"文无第一,武无第二",大家的设计理念、角度不一样,技术设计本应如此,就像一百个厨师做同样的菜,做出来的菜也有一百个样。

如果知识层偏表达,那么操作层就是偏实现支撑,这两类的视角也是不一样的,知识层更抽象,而往往我们开发人员更关心的是操作层中的具体实现类,缺乏抽象意识,这也是我们自己心中非常清楚,但别人很难理解,需要转换视角,思考通识的知识层有什么。


五、小结

在文章中主要讲述了建模的一些方法,方法虽然简单,但用熟还是需要大量的实践经验,建模分为两个阶段:第一个阶段是业务概念建模,它无关于技术,是通识的建模(知识层);第二个阶段是系统建模,基于业务概念建模的基础上,考虑具体的技术实现(操作层),遵循某些设计原则构建可落地的模型。建模的确会简化对复杂事物的认识,以学习技术框架为例,如果一头扎进源码中,很难有全局观,相反如果我们从全局对技术框架有一定的理解,再去看源码也会快很多。


作者 | 高福来(不拔)

来源 | 阿里云开发者公众号

相关文章
|
6天前
|
设计模式 监控 算法
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(通用语言体系)
【领域驱动设计专题】一文带领你透视DDD领域驱动模型的本质和设计原理分析指南(通用语言体系)
67 2
|
9月前
|
机器学习/深度学习 人工智能 自然语言处理
这 10 本书,带你了解 ChatGPT 的底层逻辑
作为一门应用型学科,机器学习植根于数学理论,落地于代码实现。这就意味着,掌握公式推导和代码编写,方能更加深入地理解机器学习算法的内在逻辑和运行机制。 本书在对全部机器学习算法进行分类梳理的基础上,分别对监督学习单模型、监督学习集成模型、无监督学习模型、概率模型四个大类共 26 个经典算法进行了细致的公式推导和代码实现,旨在帮助机器学习的学习者和研究者完整地掌握算法细节、实现方法以及内在逻辑。
171 0
|
10月前
|
存储 Kubernetes 负载均衡
K8S基础篇:概念与架构
**Kubernetes** 是一个可移植的、可扩展的开源平台,用于**管理容器化的工作负载和服务,可促进声明式配置和自动化**。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用
292 2
K8S基础篇:概念与架构
|
11月前
|
SQL 存储 缓存
第04章_逻辑架构(上)
第04章_逻辑架构
153 0
|
11月前
|
SQL 存储 缓存
第04章_逻辑架构(下)
第04章_逻辑架构
137 0
|
存储 Web App开发 Java
Android性能优化的底层逻辑
Android性能优化的底层逻辑
202 0
Android性能优化的底层逻辑
|
网络协议 数据可视化 测试技术
面向对象分析与设计的底层逻辑
真正掌握了面向对象分析和设计的方法,也体会到其中的益处,对理解业务、方案设计、编码开发都有好处。
757 1
面向对象分析与设计的底层逻辑
|
容器
框架设计思维符合语义即可使用,而不用关心底层的实现
框架设计思维符合语义即可使用,而不用关心底层的实现
204 0
框架设计思维符合语义即可使用,而不用关心底层的实现
|
新零售 存储 JavaScript
智能合约的核心思想、语法重点、编程模式、示例、规范及架构
目录 智能合约简介 智能合约例子 合约编程模式COP 合约语法 重难点 限制和规范 合约架构 什么是智能合约 一个智能合约是一套以数字形式定义的承诺(promises) ,包括合约参与方可以在上面执行这些承诺的协议。
1565 0
|
设计模式 算法 安全
洞察设计模式的底层逻辑
设计模式是开发同学经常聊到的话题,也经常被用到实际的开发项目中,熟练的人可以做到信手拈来,不熟悉的人陷入苦思冥想中。笔者认为,不仅仅要掌握设计模式的用法,更要洞察设计模式的底层逻辑,只有那样,才能做到遇到实际的问题可以使用合适的设计模式去解决。
洞察设计模式的底层逻辑