【架构】1-原理

参考：《软件架构：架构模式、特征及实践指南》

 

架构师看待事物的视角与开发人员是不同的--架构思维

架构思维：用架构的眼光或视角来看待事物。有四个重要的方面

1、要明白架构和设计之间的区别，了解如何与开发团队合作，进而使架构顺利落地

2、需要在具备技术广度同时，仍保持一定水平技术深度，支撑架构师觉察到其他人察觉不到的解决方案和可能性；

3、需要理解、分析和协调各种解决方案和技术之间的权衡

4、需要了解业务驱动的重要性及他们如何转化为架构问题的

 

传统架构和设计职责模型

• 架构师：分析业务需求以提取架构和定义架构特征，选择适合该问题域的架构模式和架构风格，以及创建组件，并将上述产出交给开发团队；

• 开发团队：负责每个组件创建类图、构建用户界面、开发和测试

     

 上图准确说明架构很难落地原因：穿越虚拟和实体转改的箭头是单向的。架构师决策常无法传达给开发团队，开发对架构改动也极少反馈给架构师。

为使架构落地，必须使架构师和开发团队之间形成双向的强关联：架构师和开发人员必须在同一虚拟团队中才能使架构落地。不仅促进双向频繁互动沟通，还促使架构师为开发提供指导和培训。

 

开发和架构师对技术的侧重不同：

• 开发：拥有很深的技术深度；

• 架构师：非常广的技术广度才能像架构师般思考，并以架构的角度看待事物。

作为架构师，技术广度比技术深度更重要。所以需要牺牲技术深度来提升技术广度。

 从开发（聚焦技术深度）转变为架构师（聚焦技术广度）意味关键的改变，通常会导致2个常见的问题：

1、架构师试图在多个领域都保持专业深度，结果无一成功，并且深陷其中；

2、专业知识没有持续更新，常使用过时技术做决策；

 

所谓的架构是不能通过Google得到的。

架构中没有对错，唯有取舍；

 

识别架构特征

架构特征：质量属性、非功能性能；如可配置性，可维护性等

架构特征的来源

1、领域问题中提取

 2、从需求中提取：

 

架构风格

反模式：Big Ball of Mud，大泥球，缺少可识别的架构结构

 

 

 

架构风格划分：