[架构之路-94]：《软件架构设计：程序员向架构师转型必备》-4-软件架构设计的通用过程

第4章 软件架构设计的通用过程

本文给出了进行架构设计的通用过程，每个步骤过程的详细方法，在后续的章节中单独探讨。

4.1 架构设计的实践脉络/步骤

4.1.1 架构设计的三大原则：看需求、把方向、细设计

（1）看透需求

所谓“全面”：特别要注意非功能性需求和约束条件！！

所谓“矛盾”：是相互制约的需求！！

所谓“追溯”：之上而下一棵树，底层的需求一定是源于上一级或上一层的进一步分解，而不是凭空产生，产生孤岛，同时高层次的需求，必须在低层次进一步分解，而不是被忽略。无论是孤岛还是断枝，都不符合追溯的原则。

（2）把方向（容易忽略）

在根据需求，确定详细的架构设计之前，需要根据部分关键性需要，确定好技术方向，并进行粗略的概念架构设计。

概念架构，不关注详细的功能模块和模块之间的接口，也不关注内部详细的流程图，它关注的是宏观层面的模块划分以及采用什么样的技术方案选型、设计模式、大的架构等信息。概念架构关注的是核心功能和关键性需求，非核心和非关键性需求被隐藏在模块内部。

这个原则是容易被忽略的，特别是非复杂系统，常常被忽略。

但对于一个新设计的复杂系统，把方向是至关重要的！！！

它关乎未来较长的一段时间是否需要推翻重来。

备注：在架构设计时，由于不设计到具体的某种编程语言和实现，因此，可以有多种架构方案，最终选择哪个方案来实现，把这个选择权留给开发人员，实现人员。

从上面的描述可以看出，概念架构主要是面向客户的，详细架构是面向开发者的。

详细架构设计与概念架构设计都是在阐述或描述目标系统，只是粗细程度不同。

详细架构设计是对概念架构设计的细化和补充！！！！

概念架构不关心详细的接口定义，只关心有哪些接口！！！只关心有哪些模块框架！！！

领域建模与概念架构的区别：

• 领域建模是需求分析的结果，概念架构是架构设计的结果

• 建模不一定是软件架构，是对业务领域外部需求结构和行为的抽象。

• 领域建模是针对业务，而不是针对软件系统；概念架构针对的目标软件系统，是构想。

• 领域建模更多的如实、抽象业务系统；概念架构是构建目标软件系统。概念架构是服务于领域建模。

（3）细设计：与程序员的接口（五大视图）

详细设计体现在如下几个方面：

• 全面视图要细致

• 功能划分要细致

• 接口定义要细致

4.1.2 架构设计的详细步骤

路径1： 1-》5-》6

路径2: 1-》2-》5-》6

路径3： 1-》3-》4-》5-》6

全路径：1-》2-》3-》4-》5-》6

4.2 架构设计详细步骤分析

4.2.1 需求分析

两纵：功能性与非功能性需求是需求的两大分类。

三横：分析功能性与非功能性需求的三大步骤

• 范围：需求的边界

• feature：边界内部的功能特征

• 上下文：业务场景

4.2.2 领域建模

业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。

它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。

业务对象模型从业务角色内部的观点定义了业务用例。

该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例。

领域模型不关心业务对象内部是如何实现的。

领域模型：为了更好的解读功能需求和业务用例而建立的对象模型。

领域模型：用图形化的方式描述需求的一种手段，是满足需要的技术方案的可视化展现。

4.2.3 关键需求提取

在复杂系统中，有些需求是次要的，有些需求是主要的，还有些需求是关键路径。

为了尽快验证系统的框架是否可行，需要建立软件系统的原型，而系统的原型就依赖于对关键需求的提取以及基于关键需求建立的概念模型。

关键需求具备如下特征：

• 关键性的业务场景

• 关键性的数据处理流程 =》关键性的功能需求

• 关键性的性能指标 =》 关键性的质量需求、约束条件

4.2.4 概念建模/概念架构设计

基于关键性需求，设计一个简化版的概念架构，有利于在复杂系统完成之前，先建立软件系统的原型，对软件系统的方案进行快速的验证，对软件系统关键性指标进行验证。

备注：

• 有了概念架构设计，就可以进行编码，完成原型代码的开发。

• 至于原型代码的开发是程序员实现，还是架构师自己完成，不同的公司做法不一样，有些公司由仿真团队完成，有些公司由架构师团队完成，有些由开发团队配合完成。

• 概念架构设计并非是必须的：对于简单系统、或已经有丰富的经验、或在已有的复杂系统之上做增量开发，而风险可控，都可能不需要概念架构设计，而直接进行一下步的详细架构设计。

• 概念架构设计并不指定详细的模块划分和详细的接口定义。

4.2.5 详细架构设计

详细架构设计，是我们常说的架构设计，“详细”体现在如下几个方面：

• 详细设计所有可能的视图，包括5大设计视图，15大设计任务

• 定义模块以及模块之间的详细接口

• 定义模块与模块之间的详细的交互流程

详细架构设计是软件最终编码实现的输入、是依据，开发团队就是基于详细的架构设计进行后续的编码设计与编码实现的。

4.2.6 架构验证

备注：

• 架构验证是在概念模型的基础之上的原型验证的进一步验证，是在详解设计完成之后，在正式编码之前，对详细架构设计进行验证。

• 架构验证不是必须的，它只针对详细架构设计中展现的“风险”进行验证。

结束语

• 至此，架构设计与验证的主要工作就已经完成，就可以开展后续程序的设计与开发工作了。

• 后续将对上述流程中的每个步骤单独进行详解。