架构设计分为三个阶段，包括Pre-Architecture阶段、Conceptual Architecture阶段、Refined Architecture阶段。
1、Pre-Architecture阶段
是架构设计的最前期阶段，其工作目标是：理解需求、建立需求大局观、确定架构设计方向。通俗的来讲，就是在架构设计之初，来全盘考虑架构设计要重点支持的关键质量目标，并在第一时间就判断这些“关键质量”之间有没有冲突关系，并制定权衡取舍的策略，也就是说，通过在Pre-Architecture阶段，理解需求，来确定架构设计的目标。
这个阶段关注对需求的把握和理解，可以采用需求结构化的方法，分析需求之间的关系。
在这里，老师说了两句话：“关键质量属性决定技术架构、关键功能决定逻辑架构”。
2、Conceptual Architecture阶段
界定系统的高层组件，以及它们之间的关系。Conceptual Architecture意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。Conceptual Architecture规定了每个组件的非正式规约及架构图，但不涉及细节。
在这个阶段，一般可以分为三个步骤：初步设计、高层分割、考虑非功能需求。
2.1 初步设计
基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。这一步并不总是需要，但对于新系统而言，这是必须的。所谓鲁棒图分析是这样一种方法：通过分析用例规约中的事件流，识别出实现用例规定的功能所需的主要对象及其职责，形成以职责模型为主的初步设计。
2.2 高层分割
对系统这个黑盒子进行高层切分，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。
2.3 考虑非功能性需求
进行架构设计时，不仅要考虑功能，也必须考虑非功能，一般可以采用目标-场景-决策表的方法。
3、Refined Architecture阶段
是相对于Conceptual Architecture而言的，它们是Architecture Design的两个层次，分别对应于“概念级”和“规约级”解决方案。在Refined Architecture中，接口占据非常核心的地位，而Conceptual Architecture并不关心明确的接口定义，只有抽象的组件和抽象的交互机制；Refined Architecture重视通过子系统和模块来分割整个系统，并且子系统有明确的接口；Refined Architecture中的交互机制是“实在”的，而Conceptual Architecture中的交互机制是“概念”化的。（如下图所示）
在这个阶段，一般采用多视图的方法。包括RUP 4+1视图，SEI 3视图。目前常用的是如下图所示的5视图方法，该方法是以4+1视图为基础，进行一定的改良而成的。
Pre-Architecture：准备架构
Pre-architecture就是架构设计的最前期阶段，其工作目标包括：理解需求、建立需求大局观、确定架构设计方向等。
准备架构阶段，最最重要的是弄清楚要做什么东西，即掌握用户需求。应该来说，整个准备阶段都围绕着“需求”来转。
我将它描述为如下过程：需求-->约束-->质量-->关键功能
初学者根据上诉步骤，一步一步来，就能够完成准备架构阶段。
1.需求
可能有人会认为“需求应该来自市场人员”，这句话并不全面，需求不应该仅仅来自市场人员。
记得本人接手的第一个项目时，市场人员告诉研发部门需要研发出一款产品，研发部门会成立一个项目小组，然后再指定一个研发人员做需求调研，写需求列表，这个做法现在觉得是非常不合理的。首先，研发人员没有市场经验，更不懂用户想要什么产品，就只能够照着别的公司的产品抄，最终肯定是抄个四不像。
下面回到话题，需求应该来自哪里？应该是一拨人讨论出来的结果，这拨人就应该包括：市场人员+产品经理+架构师+项目经理。首先一款产品是否需要做，这是市场人员和产品经理所讨论的范畴，他们决定该如何定位此款产品，产品经理根据公司的技术实力，决定能否做。那么，接下来便是了解用户需求，前期的调研工作需要市场人员来做，并形成一个“初步需求列表”。有了“初步需求列表”，架构师和项目经理就应该考虑，并弄清楚每条需求，这里为什么需要项目经理的参与呢，就是为了保证该项目的负责人能够最清晰的明确做什么，接下来才能带领队伍把握关键指标。
架构师在考虑需求的时候，如果只是笼统的来了解每个功能，这样各种需求混在一起就显得比较乱，最好可以参考ADMEMS矩阵法来进行划分：
ADMEMS矩阵法
广义功能 质量 约束
业务级需求 业务目标 快、好、省 1.技术性约束
2.法规级约束
3.技术趋势
4.竞争因素与竞争对手
5.遗留系统集成
6.标准性约束
7.分批实施
用户级需求 用户需求 运行期质量 1.用户群特点
2.用户水平
3.多国语言
开发级需求 行为需求 开发期质量 1.开发团队技术水平
2.开发团队磨合程度
3.开发团队分布情况
4.开发团队业务知识
5.管理：保密要求
6.管理：产品规划
7.安装
8.维护
从表中可以看出需求是分为层次的。
业务级需求：包含客户或出资者要达到的业务目标、预期投资、工期要求，以及要符合哪些标准、对哪些遗留系统进行整合等约束条件；
用户级需求：用户使用系统来辅助完成哪些工作？对质量要求如何？用户群及所处的使用环境方面有何特殊要求？
开发级需求：开发人员需要实现什么？开发期间、维护期间有何质量考虑？开发团队的哪些情况会反过来影响架构？
对于此三类需求弄清楚之后，就可以形成一个初步的需求列表。
基本上来说掌握ADMEMS矩阵表，前期的准备工作就算做完了。下面的小节是对其他概念做更加详细的解释。
2.约束
前面说了，整个阶段都是围绕“需求”来转，接下来的“约束”、“质量”都是对需求做限制的。那么何为“约束”？
约束：制约项目发展的因素。
首先，约束来自与需求又制约需求，比如“用户级需求”中提到了“用户群特点”的约束，就说明，本产品必须要考虑针对哪些用户群来做，要做一个儿童教育软件，就不应涉及成人的复杂理论和逻辑。这就是约束！
3.质量
质量，类似于“约束”，它更重视某一事物具备的属性。当然，有些时候可以把质量属性来当做约束，比如可移植性，可以把它看做是质量也可以当做一种约束来看。
那么，作为一个架构师该考虑哪些质量属性呢？
1.性能 2. 安全性 3.持续可用性 4.可靠性 5.鲁棒性 6.易用性 7.可测试性 8.可重用性 9.可维护性 10.可扩展性 11.可移植性 12 可互操作性。
也不是说用户要把每一个指标都做上去。有些指标之间是相互影响的。其影响关系如下（+表示促进 －表示影响 空白表示无明显作用）：
性能 安全性 持续可用性 可互操作性 可靠性 鲁棒性 易用性 可测试性 可重用性 可维护性 可扩展性 可移植性
性能 － － － － － － － －
安全性 － － － － －
持续可用行 + +
可互操作性 － － + +
可靠性 － + + + + + +
鲁棒性 － + +
易用性 － + －
可测试性 － + + + +
可重用性 － － + + + + +
可维护性 － + + +
可扩展性 － － + + +
可移植性 － + + + － +
架构师应该确定关键质量的优先级。并在《架构文档》中明确记录此要求。
4.关键功能
关键功能包含如下四个方面：1.核心功能；2.必做功能；3.高风险功能；4.独特功能。
如何区别这四个方面，实际上是靠经验和感觉。它们之间实际上是有重叠部分的。
核心功能：业务层接口所反映的功能。如，项目管理系统中，项目信息查看、添加任务等都属于核心功能；
必做功能：必做功能实际上是以客户为背景的，简单来说就是愿景；
高风险功能：顾名思义，哪些功能操作可能会涉及到安全和隐私等问题；
独特功能：实际是上诉上个功能的补集，看看还有哪些没有覆盖到的，却又很关键的功能。
架构师在设计阶段要考虑到“关键功能”所占有的比例，没有明确的标准，一般遵循：功能少的系统比例高一些，功能多的系统比例少一些。
总结
总得来说，准备阶段要做的最重要的一件事，就是弄懂需求，不管通过何种方式剖析和理解，只要弄懂架构的需求就算完事了！
实际意义
需求理解的大局观
有效处理互相矛盾的需求目标；
识别重大需求、特色需求、高风险需求；
相对短的时间内设计架构；
等等
降低架构失败风险
架构师在需求的理解、权衡、取舍和补充这些方面能力严重不足。
尽早开始架构设计
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.值得专门说明的还有“关键功能所占比例”的问题；
1、架构设计开始的三个前提条件，明确的业务需求、全面的用户需求以及典型的行为需求，如下图所示：
2、架构设计的“驱动力”：
3、对于架构设计师而言，四大约束：业务环境约束、使用环境约束、构建环境约束、技术环境约束等；
4、二维需求观
是多疑还是去相信 谎言背后的忠心 或许是自己太执迷 命题游戏 沿着他的脚步 呼吸开始变得急促 就算看清了面目 设下埋伏 真相却居无定处 I swear I'll never be with the devil 用尽一生孤独 没有退路的路 你看不到我 眉眼焦灼却不明下落 命运的轮轴 伺机而动 来不及闪躲 沿着他的脚步 呼吸开始变得急促 就算看清了面目 设下埋伏 真相却居无定处 I swear I'll never be with the devil 用尽一生孤独 没有退路的路 你看不到我 眉眼焦灼却不明下落 命运的轮轴 伺机而动 来不及闪躲 你看不到我 眉眼焦灼却不明下落 命运的轮轴 伺机而动 来不及闪躲 黑夜和白昼 你争我夺 真相被蛊惑 心从不退缩 这天堂荒漠 留给孤独的猎手
