从业务实体到动态视图的构建

在软件设计领域，常见的动态视图有时序图，协作图/通信图，状态图等。他们主要是用来表述实体或系统之间的关系。

我们先来说说最常用的时序图，它通过描述对象之间发送消息的时间顺序显示多个实体或系统之间的动态协作。使用场景：描述用例的实现，通过对象之间的交互来说明用例是如何被对象实现的。

在之前的文章《从生活中来，到生活中去，谈业务实体的抽象》中我们介绍了如何找出业务实体并建立他们之间的关系，但是他们之间的关系是静态的，没有体现出动态协作的过程。这里还是沿用之前的“送礼物”的案例来继续说明动态视图的构建：

图1 静态视图—业务实体模型

图2 动态视图——系统时序图

从静态视图到动态视图的转变需要经历如下过程：

1 业务实体到系统的转变。业务实体更偏向于概念上的描述，而系统则更偏向于从现实/实现的角度的描述。实体需要找一个地方给他管理起来，那么管理它的地方就称为系统。比如：我们的身份信息（实体）是在公安局进行管理的（系统），商品（实体）是在商店（系统）进行管理的；

这样做的原因是为了更有效的发挥实体的作用，比如说：假设我们的个人信息没地方管理，大伙儿可以随意改动，任何人都可以查阅，这样肯定是不行的。所以每一个概念上的实体都需要有相应的系统去管理它。那么一个实体是不是就对应一个系统呢？在这里，我想说大部分的情况是这样的，少量的情况可能需要多个系统来进行管理，这个还是要看具体的业务需求。

我们还是回到图1和图2，图一描述的实体和图二描述的系统基本上可以一一对应起来，唯独不一样的就是图二种多一个支付中心。我们可以暂且忽略这个“支付中心”，借助已有的礼物，用户，商品，钱包，消息通道这几个系统来描述下送礼五这个用例。在描述的过程中，会出现一个逻辑分支，我们会发现，如果钱包里的钱不够，怎么办？在现实生活中，肯定是去银行取钱，那么在虚拟世界中，同样也是需要去银行取钱，比如通过网银，支付宝，微信支付等支付渠道换取我们的虚拟货币，所以说在虚拟世界中我们需要有一个系统来处理这类事情，根据职责描述我们可以称之为“支付中心”。这样就可以满足我们的业务场景了，可见实体的抽象和系统的划分它并不是一触而就的，在刚开始通过业务实体分析我们可以梳理出我们的核心实体，建立起大框架，然后在框架之内梳理业务流程的时候，对于没有考虑到的逻辑分支，需要按照现实生活到虚拟世界的映射关系进行梳理找出其对应的实体并映射到虚拟世界中。

2 业务实体/系统之间操作步骤的实现。面向对象和面向过程的典型区别，同样是描述步骤，面向对象是先有对象，后描述业务步骤，而面向过程是没有对象抽象的这一个环节，只有步骤的实现环节，就算有封装也只是对操作过程的封装和复用。（面试过程中）

上面主要讲了由业务实体如何向系统进行转换，主要介绍方法和思想，在如何画时序图上并没有做过多的阐述，因为市面上这类工具书已经有很多了，下面主要介绍下误区以及在构建时序图中常见的一些问题。

误区一，缺乏领域划分的思想，从数据聚合的角度来构建系统。日常开发中最典型的常见就是如下图所示的API聚合层，有些公司还会氛围webapi和mapi。如果按照API聚合层的思路去设计，应付业务需求肯定是没有问题的，但是随着业务越来越复杂，这个API聚合层会越来越大，等到后续想拆分的时候由于前期没有进行模块的领域划分，导致拆分困难，难以维护，进而形成了一个单体的API层。

图3 误区

误区二，使用面向过程的思想来构建时序图。如下图所示，这里翻了两个错误：1 商品的信息是在商品系统中管理的，没有必要单独画一个mysql来体现，直接通过商品系统获取礼物信息即可，至于商品内部的实现我们可以暂且不用关心；2 在目前阶段，我们还没有谈到商品信息如何存储的问题，具体是用mysql，mongo还是pgsql，应该是在后续存储选型时考虑的，这里提到mysql或者表的谁急时典型的惯性思维或者说是典型的面向数据设计设计的思路。

关于动态视图这里，除了时序图外，还有协作图/通信图，主要描述多个参与者与系统之间的交互关系，便于在一张图上介绍全局方案。如下图所示：

协作图

动态视图构建的本质还是为了帮我们理清思路，让别人看懂你的方案，做到你懂他也懂，其次也是为了项目的传承。