软件架构设计的流程

综上所述，我们就可以比较条理化的建立软件架构设计的流程了。典型软件架构设计的

流程如下图所示。

一、业务架构概念

在构建软件架构之前，架构师需要仔细研究如下几个问题：

系统是为什么目的而构建的？

系统投运后服务于哪些利益相关者的利益？

什么角色在什么时候操作或者维护系统？

业务系统实现方法是怎样的？

整个业务系统是如何依靠系统而运转的？

为了回答这些问题，需要仔细阅读需求分析文档中的业务模型建立、问题域及其解决构

思、产品模型的构思等等前期文档，站在系统架构的角度，全面清晰的建立业务模型，包括

组织结构关系、业务功能、业务流程、业务信息交互方法、业务地理分布、业务规则和约束

条件。这个阶段的主要活动如下：

建立产品范围、目的、最终用户、业务背景等重要的初始信息。

建立完整的业务和系统的术语字典，确保项目相关人员理解上保持一致。

建立宏观层面业务的总体概念，明确总体流程、业务功能的边界、交互与协作方式，

建立系统的概念模型。

汇总业务总的组织结构与协作职能关系。

分析业务的组成节点，以及节点间交互、协同与信息的依赖关系。

分析业务节点的事件、消息，以及由此引发的状态转换关系。

汇总业务运行的基本数据模型，以便于跟踪信息的流动与格式转换。分析业务数据

的关联关系。

理解问题域以及系统需要解决的问题。

分析业务运作层面的基本业务规则与约束条件。

这个阶段的活动非常重要，架构师只有具备了这些相互关联的业务概念以后，才可能从

这些概念中抽取恰当的架构因素。

二、产品架构概念

在理解业务的基础上，我们需要进一步思考产品架构的概念，这个阶段从活动的层面看

实际上与建立业务架构概念是一样的，但是思维的重心转移到如下几个方面：

新系统投入运行以后，最高层面的业务会怎样运作？

新系统是如何解决原来工作系统的问题的？

新系统的投运，会对原来的组织结构划分发生什么样的影响？

由于新系统取代了原来的一些业务职能，业务节点的分布会发生怎样的变化？变化

后的节点间的信息又是怎样交换与依赖的？

变化后的业务事件传递又会发生怎样的变化？

新的系统加入以后，哪些业务流程将会发生重大变化？哪些不会发生变化？

业务的状态转换关系将会如何随着新系统地加入而改变？

业务的数据模型将会如何随着业务流程的变化而变化的？

新系统地加入，将会如何影响新的业务规则和约束？

从这些角度出发，我们会重新构建未来新系统投运以后的业务规则，相应的新规则也需

要建立，这就实现了业务过程的重构。

三、建立稳定的架构基线

在对业务领域与问题域有深刻的理解以后，我们需要继续研究如下一些问题：

这个复杂系统应该分成多少和哪些子系统？

子系统是如何分布在不同的业务节点或者物理节点上的？

这些分散的子系统将提供哪些接口？这些接口如何进行交互？

各个子系统需要交互哪些数据？

每个单独的子系统，所需要实现的功能有哪些？

整个系统对各个子系统有哪些功能、性能和质量上的要求？

“基线”这个词有两个意义：

这个阶段将会对整体架构策略做出重大的设计上的决策。一旦作出了这些决策，后

续开发没有重大情况不允许变动。

这个阶段完成的工作，本身就是架构阶段的重要成果，需要广泛认同、集体遵守以

及具备强制的约束力。

尽管在后期的演变中，这样的基线实际上还会不断的精化和优化，但最初下功夫构建稳

定的架构基线是十分必要的。这个阶段的活动如下：

校验与确认前期所有的业务架构与产品架构的信息，必要的时候补充相应的信息。

修订和增补术语字典，确保所有的相关人员对术语有相同的认知。

把整个系统功能进行拆分，并且分解到不同的运行节点上，构建不同的系统集和子

系统，在全局范围内划分接口与交互规则。

汇总系统/子系统接口信息，便于检索与浏览。

规划整个系统的通信链路、通信路径、通信网络等传输媒介。

把产品架构概念中的业务职能与系统功能相对应，从而确保满足业务要求。

分析系统/子系统在运行起动态协作需要交互的信息。

构建和模拟整个系统在业务环境下的动态特性，规划全系统内部状态变化过程、触

发的事件及约束条件。

详细汇总各个子系统间信息传递的过程、内容以及其它辅助信息。

根据初始的数据模型构建数据物理模型。

汇总质量上对系统的要求，并把这些质量要求细化分解，量化到各个子系统中去。

构建整个系统与子系统的构建和演化计划，在迭代过程中构建整体项目规划和初始

的迭代规划。

按固定时段预测技术的演化，汇总整个系统的应用技术及其演化。

分辨与汇总整个系统在不同阶段必须遵循的标准。

把业务约束映射到各个子系统，必要时附加 IT 业务约束。

四、子系统架构的设计与实现

通过上述各主要过程，我们已经实现了一个重要的总体架构基线。所有的子系统设计都

是在这个庞大的架构基线约束下展开，至此，首席架构师逐渐淡出，让位于子系统架构设计

师。子系统架构设计师的任务是继续分解、细化、设计各个子系统。在这个阶段，将会考虑

更加细节的问题，为后来的构件设计与单元设计作准备，我们需要考虑的问题如下：

规划给该子系统的功能是否可行？

在整个子系统的范围内，又能分解成什么子功能集？

在整个子系统的范围内，又能把哪些子功能合并到某些构件中去？

这些构件与子功能集是如何通过接口与子系统衔接的？

事实上子系统架构设计本身就是一个完整的系统设计，所区别的是视野集中到子系统的

范围内，这个阶段的活动如下：

校验与确认前期与该子系统相关的业务架构与产品架构的信息，必要的时候补充相

应的信息。

增补与本子系统相关的术语字典，确保所有的相关人员对术语有相同的认知。

把整个子系统功能进行拆分，并且分解到不同的构件节点上，构建不同的子功能集，

在子系统范围内划分接口与交互规则。

汇总子系统/构件接口信息，便于检索与浏览。

规划整个子系统的通信链路、通信路径、通信网络等传输媒介。

把产品架构概念中的子业务职能与构件功能相对应，从而确保满足业务要求。

分析子系统/构件在运行起动态协作需要交互的信息。

构建和模拟整个子系统在业务环境下的动态特性，规划子系统内部状态变化过程、

触发的事件及约束条件。

详细汇总各个构件间信息传递的过程、内容以及其它辅助信息。

根据初始的数据模型构建子系统相关的更详细的数据物理模型。

根据质量上对子系统的要求，并把这些质量要求细化分解，量化到各个构件中去。

构建整子系统的构建和演化计划，在迭代过程中构建子系统项目规划和更详细地的

迭代规划。

按固定时段预测技术的演化，汇总子系统的应用技术及其演化。

分辨与汇总子系统在不同阶段必须遵循的标准。

把业务约束映射到各个构件，必要时附加 IT 业务约束。

五、构件与实现单元的设计

进入构件设计阶段也就是进入了详细设计阶段。这个阶段主要的工作就是接口与功能设

计。在迭代模型下，这个阶段很大程度上是在迭代过程中完成的，由某个设计人员带领全体

开发团队进行分析和设计。

在这个过程中，我们应该考虑在小粒度架构中如何使产品需求变更不至于对产品质量造

成影响，还需要考虑业务概念模型与产品功能块有相应的追溯和回溯关系。这些问题，我们

将会在后面用适当的篇幅进行讨论。

小结：

大型复杂项目的成功依赖于合理的项目组织，这种组织概念包括人力资源的组织和产品

架构的组织两个方面。敏捷项目管理为这两种合理的组织提供了思维基础，为项目的成功提

供了保证。一个典型的例子是 20 世纪 90 年代加拿大空中交通系统项目（首席架构师：Philippe

Kruchten）。150 个程序员被组织到 6 个月的长周期迭代中。但是，即使在 6 个月的迭代中，

10～20 人的子系统，仍然把任务分解成一连串 6 个为期一个月的小迭代。正是这个项目的

实践成功，Philippe Kruchten 才成为 RUP 的首倡者。

敏捷过程的提出直接影响到架构设计的核心思维，正是因为敏捷过程的提出，才有了架

构驱动、弹性架构和骨架系统这些理念。也直接影响到需求分析方法、项目规划和估计方法

等一系列领域的新思维。甚至推动了业务敏捷以及与之相适应的基于服务的架构的提出。这

些观念的提出又更加推动了软件工程学向更高的层次发展。

下面我们将讨论几个专题，但讨论的时候希望研究一种思考问题的方法，从而为大家解

决更广阔的问题提供一个思维的平台。这些专题并不是独立存在，而是融合在本章所讨论的

各个阶段之中。再一次强调，方法和技术是会变化的，但优秀的思维方式是永恒的！