一同事问：你是新来的DBA吧？我：不是啊，为什么这么问？ 同事：那是测试的？ 我：不是啊。 同事：哦，看你最近对应用调优、对DB调优，提出那么多好建议，还以为你是DBA呢。 我：哦，我打杂的，有事您说话，我样样行，但是样样都挺轻松。需求架构开发测试设计管理什么都做，欢迎交流。
架构重构是难点、痛点、未来热点 ----温昱
听说温昱老师，要出一本架构重构的书，期待。
架构设计分为三个阶段，包括Pre-Architecture阶段、Conceptual Architecture阶段、Refined Architecture阶段。
1、Pre-Architecture阶段
Pre-Architecture是架构设计的最前期阶段，其工作目标是：理解需求、建立需求大局观、确定架构设计方向。通俗的来讲，就是在架构设计之初，来全盘考虑架构设计要重点支持的关键质量目标，并在第一时间就判断这些“关键质量”之间有没有冲突关系，并制定权衡取舍的策略，也就是说，通过在Pre-Architecture阶段，理解需求，来确定架构设计的目标。
这个阶段关注对需求的把握和理解，可以采用需求结构化的方法，分析需求之间的关系。
在这里，老师说了两句话：“关键质量属性决定技术架构、关键功能决定逻辑架构”。
2、Conceptual Architecture阶段
Conceptual Architecture界定系统的高层组件，以及它们之间的关系。Conceptual Architecture意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。Conceptual Architecture规定了每个组件的非正式规约及架构图，但不涉及细节。
在这个阶段，一般可以分为三个步骤：初步设计、高层分割、考虑非功能需求。
2.1 初步设计
基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。这一步并不总是需要，但对于新系统而言，这是必须的。所谓鲁棒图分析是这样一种方法：通过分析用例规约中的事件流，识别出实现用例规定的功能所需的主要对象及其职责，形成以职责模型为主的初步设计。
2.2 高层分割
对系统这个黑盒子进行高层切分，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。
2.3 考虑非功能性需求
进行架构设计时，不仅要考虑功能，也必须考虑非功能，一般可以采用目标-场景-决策表的方法。
3、Refined Architecture阶段
Refined Architecture是相对于Conceptual Architecture而言的，它们是Architecture Design的两个层次，分别对应于“概念级”和“规约级”解决方案。在Refined Architecture中，接口占据非常核心的地位，而Conceptual Architecture并不关心明确的接口定义，只有抽象的组件和抽象的交互机制；Refined Architecture重视通过子系统和模块来分割整个系统，并且子系统有明确的接口；Refined Architecture中的交互机制是“实在”的，而Conceptual Architecture中的交互机制是“概念”化的。（如下图所示）
在这个阶段，一般采用多视图的方法。包括RUP 4+1视图，SEI 3视图。目前常用的是如下图所示的5视图方法，该方法是以4+1视图为基础，进行一定的改良而成的。