下载掌阅APP，畅读海量书库
立即打开
从根本上来说，信息交换指的是在架构设计的不同阶段，我们对系统的理解是什么，这种理解在经过多方沟通之后通常以模型的方式呈现出来，因此信息交换的核心是模型。本章首先介绍系统描述的3种维度，以及由此得出的系统模型分类。接着简要介绍本书架构落地方法中将要涉及的系统模型。最后，由于模型本身也处在一个不断演变的过程中，因此，我们将探讨这种演变本身折射出的系统认知的变化。
在推导架构知识模型时，提到了架构设计是由软件系统“干什么”来推导出软件系统“是什么”和“怎么干”的过程。事实上，这个定义中隐含了描述系统的3个维度：功能维度、结构维度和行为维度。
功能维度是系统描述的第一个维度，它描述了系统“干什么”。通常情况下，一个系统存在的价值在于可以满足利益攸关人一定的需求或提供某种价值。这些需求和价值主要是由系统所提供的功能实现的。例如，如果我们需要购买一辆汽车，主要考虑的是它能否提供载客、运输物品等功能，而不是其他方面。
功能维度可以进一步分为两类：外部功能和内部功能。其中，外部功能主要决定了系统所能带来的价值。在评估外部功能时，可以将系统视为一个黑盒子，只关注于它在与外界交互时可以提供哪些功能或价值。例如，汽车的载客、运输物品就是它能够提供给用户的外部功能。
内部功能通常是为了实现系统的外部功能，即系统内部需要哪些功能来支撑外部功能。仍以汽车为例，由于汽车要实现载客、载物的外部功能，那么汽车内部需要发动机来实现启动加速，需要方向盘来实现转向，需要后备厢来实现装载物品等功能，因此这些都属于内部功能的范畴。
对于一个系统来讲，其外部功能和内部功能同等重要。外部功能定义了系统的边界，是系统与外界交互的窗口。我们对系统的认识、体验等都是通过外部功能来实现的。然而，内部功能同样不可或缺，内部功能是否配备合理，直接决定了外部功能的实现效果。
对于认知一个系统来说，将系统的外部功能和内部功能分开是很有帮助的。本书在介绍需求获取、系统架构设计时也会强调：在系统研发的不同阶段需要关注的功能维度是不一样的，外部功能和内部功能的划分能够让我们适当屏蔽一些不必要的因素，从而将注意力放到重要因素上。
结构维度描述了系统“是什么”。结构维度比较直观，它首先从静态角度描述了系统中包含的各个实体。例如，汽车的结构包含了方向盘、轮胎、发动机等实体，而一个电商系统的结构通常包含了订单、支付、购物车、物流等实体。除此之外，在结构层面上还需要考虑这些实体之间的关系，比如汽车中的方向盘和轮胎就存在某种交互关系。总而言之，系统中的各个实体以及实体之间的关系就构成了一个系统的结构。
值得注意的是，系统的结构和功能之间有着密切的关系。一方面，系统的结构是基础，它在一段时间内通常是静态的，体现了系统本身的样貌或形态。然而，我们也知道，一个系统存在的主要目标是为客户创造价值，而这种价值只有依赖功能的实现才能达成。如果一个系统不被使用，那就相当于没有价值。因此，系统的结构需要通过功能实现才能体现出价值。另一方面，系统的功能是目标，它在实现过程中一定需要依赖系统的结构，不论这种结构是物理的还是虚拟的。
行为维度是系统描述的第三个维度，它描述了系统“怎么干”。通俗来说，若要使得一个系统能够发挥其外部或内部功能，通常必须有一个行为体介入，行为体的操作引发了结构中实体的参与，并且每个实体在完成自己对应的任务之后，再传递给下一个实体。这些链路串联起来就构成了一个行为。行为主要包括行为体（可以是用户或定时任务等）、结构中的实体以及相应的动作过程。
同时不难看出，行为维度很好地将功能和结构关联起来。行为触发的目的在于实现某一个特定的功能。然而，功能只描述了系统“做什么”，而行为则需要进一步描述如何通过执行各种动作来实现该功能，并且这个过程还需要依赖结构参与才能顺利完成。
简单来说，模型的作用在于能够帮助我们更好地理解系统。但在大多数情况下，模型只表达了系统在某一个视角下的形态，而屏蔽掉了其他视角，这么做的目的是让我们更好地聚焦于当下要解决的问题的范围。因为，如果需要考虑到每一个视角，那么很容易迷失在众多的细节中，反而失去了模型的价值。
对一个复杂的系统来说，它就像是一面多棱镜，透过不同的视角去观察，景象是完全不同的。举一个简单例子，架构师可能会将软件系统看作一组子系统之间交互关系的组合；而程序员更倾向于认为软件系统是代码和API接口的组合；运维人员则把软件系统看作服务节点之间的组合。这时候，不同维度的模型就可以帮助不同的职能角色更好地表达和理解系统。接下来探讨一下系统的模型分类。
从是否真实存在的角度来看， 模型可以分为概念模型和物理模型两大类 。其中，物理模型代表该模型是真实存在的。例如，汽车仿真模型用于模拟一个现实中真实存在的物体，又如敏捷开发中的MVP（最小产品集），或者一张数据库物理表，它们均属于物理模型。相反，概念模型则代表一种只存于想象之中的抽象概念。例如，在进行架构设计时所绘制的价值模型、数据ER模型等，它们在现实或虚拟世界中不存在任何的可见形式，因此属于概念模型的范畴。
我们可以从软件系统研发的角度再来讨论一下概念模型和物理模型。对软件系统来说，实际上是一个将现实世界映射到虚拟世界的过程。以电商系统为例，它就是将现实中的商场、人、商品、物流等元素在虚拟世界中重建出来。在映射的过程中，通常会先对现实世界进行建模，这个建模过程就形成了现实世界的物理模型。接下来，会将这个物理模型又转换成计算机世界中的概念模型。最后，再使用计算机语言等工具将该概念模型落地为软件系统的物理模型。图2-1简要展示了上述的软件系统研发映射过程。
图2-1 软件系统研发映射过程
从系统描述的三个维度来看，概念模型和物理模型又可以进一步按照3个维度进行划分，即每种模型又可以细分为功能、结构和行为3种模型，参见2.1节。
如果我们观察一下目前业界流行的几种建模语言，可以发现它们提供的模型基本可归入功能模型、结构模型和行为模型。例如，UML中的用例图属于功能模型，类图、组件图和部署图都属于结构模型，而时序图和活动图等则属于行为模型。
本书后面将要介绍的架构落地方法涉及4个阶段：需求分析、架构设计、系统实现和系统维护。每个阶段都有输入和输出，上一阶段的输出又作为下一个阶段的输入，这些输入和输出均可视为模型。本节简要介绍一下架构落地方法中涉及的模型，让读者对架构落地方法先有一个直观的认识，如图2-2所示。至于每种模型如何实现将在第三部分进行介绍。
图2-2 架构落地过程及各阶段模型
首先，在需求分析阶段，输入是捕获的需求，它可以使用清单、二维矩阵，或本书中介绍的多维度圆形模型来表示。在该阶段，我们主要关注的是系统能提供哪些功能，因此需求类模型属于功能模型。通过需求分析将会产生一系列的模型。其中，上下文图用于界定系统的范围和边界；价值链/价值流、服务蓝图和业务流程可以协助我们划分领域、子领域、微服务、数据实体等。在需求分析阶段的模型中，上下文图属于结构模型，价值链/价值流、服务蓝图均属于功能模型，而业务流程则属于行为模型。
其次，在架构设计阶段，我们需要进行应用架构、数据架构和技术架构的具体设计工作。在需求分析阶段，我们更多是在界定系统的范围以及系统需要提供的功能，此时系统更像是一个黑盒。但是到了架构设计阶段，我们需要逐步打开这个黑盒子，并填入必要的内容来支撑提供各种功能。因此，架构设计阶段的模型基本属于结构和行为模型。例如，应用分层架构图和应用交互图均属于结构模型，而业务场景图则属于行为模型。
第三，在系统实现阶段，我们需要将架构设计阶段的概念模型进行物理实现。例如，编码时经常使用的类图、时序图都属于这一阶段的常用模型，并且这些模型主要属于结构和行为模型的范畴，只是与架构设计阶段的模型相比，系统实现阶段的模型更加微观化。
最后，在系统维护阶段，由于系统会不断新增功能或对存量功能进行维护更改，因此该阶段使用到的模型也都是需求分析、架构设计和系统实现阶段的模型。
我们知道，各类模型并不是同一时间出现的，而是随着系统复杂度的提升逐步出现的。本节将从时间维度，以面向过程、面向对象和面向领域（DDD）设计为主线来探讨模型的演进过程。本质上，模型也代表了我们对系统的认知。因此，我们也可以从模型的演进中了解系统认知方式的变化。
无论是面向过程、面向对象还是面向领域的软件开发方法，都包括分析、设计和编程三个环节。具体来说，在面向过程的软件开发方法中，分析、设计和编程都是以过程为主导；在面向对象的软件开发方法中，分析、设计和编程都是以对象为主导；而微服务时代的DDD开发方法，尽管从概念上看是面向领域的，然而在限界上下文层面的分析、设计和编程也是面向对象的，差别主要在于通过建模划分领域、子领域和限界上下文的战略设计阶段。
因此，模型的演进主要关注两个问题：一是从面向过程发展到面向对象，模型及其背后的系统认知方式究竟发生了哪些变化；二是相比面向对象，DDD的战略设计阶段的模型又起到了哪些作用。
对于第一个问题，我们经常听到面向过程是以计算机为中心的，而面向对象则是以人为中心的说法。为了更好地进行对比，我们尽可能简化计算机的运行过程。
在计算机中主要有两个部件参与程序的执行：CPU和内存，其中CPU用于执行指令，而内存用于存储数据。在实际操作中，CPU按照预设好的顺序逐条读取和执行指令。与此同时，在执行过程中需要输入和输出各种数据信息，并且上一过程的输出通常作为下一过程的输入的一部分。简而言之，我们可以将CPU的运行过程想象成是一条按照一定顺序运转的流水线，该流水线被划分成多个过程，如图2-3所示。
图2-3 CPU运行的简化过程
可以发现，计算机运行的模型是基于面向过程的。在这个模型中，每次程序运行都可能包括多个过程（即函数），而每个过程又包含了许多指令，每个指令需要输入数据并产生相应的输出数据。这些指令按照一定的顺序逐步执行下去，最终完成整个程序的执行。即便是CPU在处理程序中存在while循环、if-then跳转等指令时，也是按照预设好的顺序来逐条读取和处理的。
下面再来看一下面向过程分析时的常用模型与计算机的运行模型又有哪些相似之处？面向过程的软件开发方法大致出现于20世纪70年代，当时在进行软件系统需求分析时，更多关注系统内部处理流程和数据结构问题，并采用类似数据流图、状态转换图等建模方法来进行描述。以业界比较知名的SASD方法为例，它在分析阶段使用到的模型是DFD，这是一种数据流的转换方法。图2-4展示了考生登记的DFD数据流图示例。其中，圆角框代表了要执行的任务，而箭头代表了输入和输出的数据。
图2-4 考生登记的DFD数据流图
不难看出，SASD所采用的DFD分析方法和计算机执行程序的方式基本相同，两个模型的核心节点描述的都是过程，即都是面向过程式的。也就是说，在面向过程时代，我们是从计算机的视角去看待现实世界中的系统的，并将现实世界中的系统直接转换成计算机可以理解的过程式模型。当然，这样做尽管有助于描述和处理系统内部的流程和数据结构问题，但同时也带来了代码难以维护、扩展性差、耦合度高等难题，为此还引发了第二次软件危机。
进入面向对象分析时代之后，人们开始更加注重对问题领域进行抽象描述。在该阶段，也开始大量使用UML中的用例图、类图等模型，并且面向对象模型中的核心节点大多变成了对象。例如，用例图中的节点主要是用户和系统，而类图里的节点是实体对象等。同样以考生登记为例，在面向对象模型中，它的用例图如图2-5所示。
图2-5 考生登记的用例图
此外，从模型的类型上看，面向过程时代所使用的分析模型（如DFD模型）大致属于行为模型。相比之下，面向对象时代主要使用的分析模型（如用例图等）则属于功能模型。
那么这两种模型有哪些不同之处呢？首先，它们的服务对象不同，面向过程的行为模型主要服务于计算机系统，而面向对象的功能模型则更侧重于用户的需求和期望；其次，它们面对需求变化时的灵活性相差较大。面向过程的行为模型中的数据流或过程流均是动态的，如果需求发生变化，则对应的数据流和过程流也必须进行相应调整。而面向对象的功能模型和结构模型均为偏静态的，只是其中对象的行为是动态的。因此，当需求发生变化时，我们只需要通过多态实现不同的行为方法即可满足新需求，不会影响已有组件或模块的功能。
总体来说，从面向过程到面向对象的转变主要体现在两个方面。一是整体思维的运用。相比面向过程，面向对象是在“对象”这个整体层面去定义和描述问题，而变量和函数则处于个体层面。同时，面向对象中利用“对象”将个体层面的“动”封装起来，对外统一暴露整体的“静”，从而解决了面向过程模型的复用性、可扩展性等问题；二是主客体思维的转换，在人和计算机构成的主客体世界中，过程是计算机的思维方式的主体，而对象是人类思维方式的主体。面向对象方式是围绕人的价值进行思考的，从而大大激发了对软件系统的需求，也促进了软件行业的繁荣。
对于第二个方面的问题，即相比面向对象，为什么DDD增加了战略设计阶段的模型呢？这主要是由系统复杂度的进一步提升导致的。面向对象产生在20世纪八九十年代，那时的系统主要面向的是企业中某一个部门或者业务领域，而到了21世纪，跨部门、跨领域或跨组织的系统不断涌现，传统面向对象的分析模式已经无法解决此类复杂系统所带来的问题，因而出现了DDD和业务架构建模等新兴的理念与方法。关于面向对象和DDD的进一步探讨请参见7.4节。
架构设计是一个需要架构师与业务、开发、运维等多个角色进行沟通协作的过程，而沟通的本质是信息的交换。而且，只有确保信息交换准确无误，才能建立可靠的基础来实现架构落地和演进。因此，信息交换是架构知识模型中的一个基础维度。
而在架构设计中，模型是信息交换的主要工具。本章从系统描述的三种维度（即功能、结构和行为）出发，得出了系统的三大类模型：功能模型、结构模型和行为模型，并以架构落地过程中用到的具体模型为例，希望加深读者对3种不同类型模型的理解。此外，通过面向过程到面向对象转变中的模型变化，进一步探讨了系统认知方面产生的重大转变。