架构设计中各个步骤的位置架构
如下是对架构设计的每一个步骤，进行总括的描述测试
1 需求分析
需求分析，是不少活动的统称，它是“架构设计过程”中第1个大的工做步骤。
需求分析活动输出的“需求”，必须涵盖功能、质量、约束这三个方面，这些是后续设计活动所须要的。需求分析工做涉及的“技能项”较多，整体而言可总结为“两纵三横”，如图所示：
架构设计
· 【一纵】需求沟通。持续伴随需求分析过程的，是需求沟通、需求启发、需求验证等活动，这些活动都要求需方和开发方紧密协同、精诚合做。“闭门造需”危险大了。
· 【二纵】非功能需求的肯定。真实的实践中，肯定非功能需求是一个持续的过程，是持久战。究其缘由，这是非功能需求的范围广形成的，不管是技术仍是业务、不管是甲方仍是乙方，均可能有这样那样的非功能需求。想“一蹴而就”地定义非功能需求是不现实的。
· 【三横】需求分析主线。从肯定系统目标开始，后续凭借“范围+Feature+上下文图”三剑客研究高层需求，再后续创建开发人员较熟悉的用例模型。
作不到“追根溯源”的需求分析，每每会失败。所以，咱们补充图4-6来强调需求分析工做的主线是“肯定系统目标→研究高层需求→创建用例模型”，需求从“高飘”到“落地”，成果项从“目标列表”到“范围框图 + Feature树 + 上下文图”到“用例图 + 用例规约”，需求跟踪脉络清晰可辨。
设计
需求分析的主线体现“追根溯源”blog
2 领域建模
领域建模，是以提炼领域概念，创建领域模型为目的的活动。领域建模实践的精髓是“业务决定功能，功能决定模型”，理解了这个理念，评审领域模型也变得再天然不过了。
领域建模活动的输入：一是“功能”，二是“可扩展性”具体要求。接口
功能指目前所须要的，可扩展性指之后须要的说到底，都是“功能”，由于领域模型必须能支持在《软件需求规格说明书》中规定的“如今的功能”，还应该支持随着业务发展而出现的“将来的功能”。这两种功能，就是驱动领域建模的因素，以及评审领域模型的依据。开发
3.肯定关键需求原型
架构面前全部需求一概平等？不可能。关键需求决定了架构的大方向。class
具体而言，为了肯定“关键功能”，一要关注“功能需求”，二要研究“约束需求”；为了肯定“关键质量”，一要关注“质量需求”，二要研究“约束需求”。扩展
4.概念架构设计
概念架构是高层架构成果的核心，框定了架构大方向，是甲方规划、乙方投标的评定关键。
概念性架构界定系统的高层组件，以及它们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，能够与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每一个组件的非正式规约及架构图，但不涉及接口细节。
概念架构设计要“直指”的、以之为输入的，是“关键需求”。
针对不一样需求（功能或者质量），须要运用不一样“技能项”，鲁棒图建模、目标-场景-决策表，很是实用。
概念架构设计的“输出”是“1个决定、4个选择”：
1）决定如何划分顶级子系统；
2）架构风格选型；
3）开发技术选型；
4）二次开发技术选型；
5）集成技术选型。
5 细化架构设计
细化架构和概念架构的关键区别之一是：概念架构没有设计到“模块 + 接口”一级，而细化架构必须关注“模块 + 接口”。
下图列出了细化架构设计的5个设计视图、15个设计任务。
· 细化架构要为“需求”而设计。关键对比：概念架构设计的输入是“关键需求”、而不是泛泛的全部“需求”。
· 细化架构要在“概念架构”的设计思想下进行。
· “领域模型”，一方面影响着“逻辑架构视图”的“领域模型设计”，另外一方面影响着“数据架构视图”的“存储格式设计”。
4.2.6 架构验证
若有必要，须要进行架构验证。
架构验证的输出成果是“架构原型”。和通常的开发不一样，架构原型的开发不是要完美地、无Bug地实现功能，而是在“细化架构”的整体指导下，仅把存在“风险”的那些设计尽早开发出来，而后经过执行测试等手段判断“风险”是否解决，以下图所示。
参考：温昱《软件架构设计》