一线架构师实践指南总结（二）—— Pre-architecture

什么是Pre-architecture

Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等。

实际意义

需求理解的大局观
有效处理互相矛盾的需求目标；
识别重大需求、特色需求、高风险需求；
相对短的时间内设计架构；
等等

降低架构失败风险
架构师在需求的理解、权衡、取舍和补充这些方面能力严重不足。

尽早开始架构设计
Pre-architecture阶段的好处：能够在需求没有“全面完成”的情况下开始架构设计。
为了尽早开始架构设计，需要做好：让架构师参与需求分析工作；不能被动地等待完善的《软件需求规则说明书》出现的那一刻。
只要满足下面3个条件就可以开始架构设计工作：
1.有了明确的业务需求：必须保证甲、乙双方就建设系统的目标达成共识，《愿景文档》经过正式评审，并且明确了投资、工期标准、整合等约束条件；
2.了解全面的用户需求：系统能帮助用户干什么、不能干什么已经非常明确。如果采用用例技术，表现为“用例图”比较完善，没明显遗漏；
3.有了典型的行为需求；如果采用用例技术，表现为核心功能的《用例约束》已经定义；

明确架构设计的“驱动力”
除了需要关注《软件需求规格说明书》之外，必须关注其他很多因素，最终理性地确定真正的架构设计“驱动力”。

实践要领

不同需求影响架构的不同原理，才是架构设计思维的基础
“需求决定架构”是对的，但不同需求影响架构的不同原理，才是架构设计思维的基础。
不同需求是如何以不同原理影响架构设计：

二维需求观与ADMEMS矩阵方法
ADMEM方法提倡的“二维需求观：

观念是行为的向导，有怎样的观念存在，就有怎样的行为方式产生。

关键需求决定架构，其余需求验证架构
关键需求决定架构：功能需求做减法；质量属性需求做加饭；约束性需求做加法；

Pre-architecture阶段的4个步骤

需求结构化

需求结构化可以将复杂的需求集合梳理得井井有条，为进一步分析不同需求之间的联系、识别遗漏的重要需求打下坚实的基础。

需求结构化要怎么做？
1.超越《软件需求规则说明书》
需求文档往往不够全面；
需求经常变更，仅依赖需求文档往往使架构设计工作非常被动；
架构师通过需求结构化真正全面地“鸟瞰”需求大局，就必须超越《软件需求规则说明书》；
能够摆脱对《软件需求规则说明书》提交时间、文档质量、内容变更的“呆板依赖”；

2.ADMEMS矩阵

业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件。
用户级需求：用户使用系统来辅助完成哪些工作？对质量有何要求？用户群及所处的使用环境方面有何特殊要求？
开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？

需求还要从下面3个方面考虑：
功能需求：更多体现各级直接目标要求。
质量属性：运行期质量 + 开发期质量。
约束需求：业务环境因素 + 使用环境因素 + 构建环境因素 + 技术环境因素

分析约束影响

约束性需求中隐藏了大量的风险因素。有经验的架构师都懂得主动分析约束影响，识别架构影响因素，以便在架构设计中引入响应决策予以应对（尽早识别风险）。

分析约束影响的方法
1.约束分类方式
ADMEMS对约束分类方式进行革新，使它更符合实践的需要。不仅注意到约束对架构设计的重大影响，还强调约束分类理论应该直接体现“这些约束来自于哪些涉众”。
如下图所示，4类约束在ADMEMS矩阵中表明：业务环境、使用环境、构建环境应分别考虑客户、用户、开发方这3类涉众，技术环境则与3类涉众都有关。

2.使用Big Picture理解约束

3.使用ADMEMS矩阵方法辅助约束分析
从本质讲，分析约束影响就是分析各个需求项之前的关系，并发现被遗漏的需求。所以，将需求“化复杂为清晰”的ADMEMS矩阵方法可以作为分析约束影响的基础——即在需求项清晰定位的前提下，找到不同需求之间的关系、发现遗漏需求。
ADMEMS矩阵方法应用法则：
推导法则：从上到下，从右到左。
查漏法则：重点是质量属性遗漏。

确定关键质量

确定关键质量目标意义
指定错误的质量属性目标（包括遗漏重要的质量属性），将面临客户不满、项目返工、同事抱怨……

确定关键质量主要完成
1.根据系统所在领域的特点及系统规模等因素，确定架构设计重点支持哪些质量属性（例如高性能、可扩展性…）
2.分析上述质量属性之间的制约关系，第一时间指定权衡折衷的具体策略（例如明确高性能是第一位，可扩展性和高性能相矛盾时应照顾高性能要求，是否引入支持可扩展性的涉及需经过架构组评审）

确定关键质量的5大原则
1.分类合适+必要扩充
2.考虑多方涉众
3.检查性思维
4.识别矛盾+划定优先级
5.严格程度符合领域和规模特点

确定关键功能

为什么不是“全部功能作为驱动因素”
功能影响架构具体原理：职责协作链：

不同功能的职责协作链之间可能有职责的重叠；在功能数量比较多的时候，职责重叠将是不可避免的。既然如此，没必要将所有功能都一视同仁地研究一遍。相反，在所有功能中筛选一个功能子集，研究功能子集中每个功能的职责协作链，从而识别出组成系统的所有职责单元。

确定关键功能的4条规则

1.核心功能
2.必做功能
3.高风险功能
4.独特功能
另外，确定关键功能子集时，必须注意：
1.“关键功能子集”的确定并不存在“标准答案”；
2.值得专门说明的还有“关键功能所占比例”的问题；