共计 996 个字符，预计需要花费 3 分钟才能阅读完成。
以下是对架构设计的每个步骤，进行总括的形容
1 需要剖析
需要剖析，是很多流动的统称，它是“架构设计过程”中第 1 个大的工作步骤。
需要剖析流动输入的“需要”，必须涵盖性能、品质、束缚这三个方面，这些是后续设计流动所须要的。需要剖析工作波及的“技能项”较多，总体而言可总结为“两纵三横”
2 领域建模
领域建模，是以提炼畛域概念，建设畛域模型为目标的流动。领域建模实际的精华是“业务决定性能，性能决定模型”，了解了这个理念，评审畛域模型也变得再天然不过了。
领域建模流动的输出：一是“性能”，二是“可扩展性”具体要求。
性能指目前所须要的，可扩展性指当前须要的说到底，都是“性能”，因为畛域模型必须能反对在《软件需要规格说明书》中规定的“当初的性能”，还应该反对随着业务倒退而呈现的“将来的性能”。这两种性能，就是驱动领域建模的因素，以及评审畛域模型的根据。
3. 确定要害需要
架构背后所有需要一律平等？不可能。要害需要决定了架构的大方向。
具体而言，为了确定“要害性能”，一要关注“性能需要”，二要钻研“束缚需要”；为了确定“要害品质”，一要关注“品质需要”，二要钻研“束缚需要。
4. 概念架构设计
概念架构是高层架构成绩的外围，框定了架构大方向，是甲方布局、乙方招标的评定要害。
概念性架构界定零碎的高层组件，以及它们之间的关系。概念性架构意在对系统进行适当合成，而不陷入细节。借此，能够与管理人员、市场人员、用户等非技术人员交换架构。概念性架构规定了每个组件的非正式规约及架构图，但不波及接口细节。
概念架构设计要“直指”的、以之为输出的，是“要害需要”。
针对不同需要（性能或者品质），须要使用不同“技能项”，鲁棒图建模、指标 - 场景 - 决策表，十分实用。
概念架构设计的“输入”是“1 个决定、4 个抉择”：
1）决定如何划分顶级子系统；
2）架构格调选型；
3）开发技术选型；
4）二次开发技术选型；
5）集成技术选型。
5 细化架构设计
细化架构和概念架构的要害区别之一是：概念架构没有设计到“模块 + 接口”一级，而细化架构必须关注“模块 + 接口”。
4.2.6 架构验证
如有必要，须要进行架构验证。
架构验证的输入成绩是“架构原型”。和个别的开发不同，架构原型的开发不是要完满地、无 Bug 地实现性能，而是在“细化架构”的总体领导下，仅把存在“危险”的那些设计尽早开发进去，而后通过执行测试等伎俩判断“危险”是否解决，如下图所示。
