架构方法周总结第一周作业「架构师训练营第 1 期」

1. 架构师是做什么的

编写架构设计文档

开发编程框架

重构软件代码

设计系统架构

进行技术选型，解决技术应用中的问题

优化系统性能

模块分解与微服务架构重构

保障系统安全与高可用

大数据应用

技术创新

沟通管理

2. 软件架构是什么

如果你盖一间草房，你不用设计，只需要知道有屋顶，有门，有窗，可以把这些固定住，不怕风吹雨打，就可以了。

如果你盖一间砖瓦房，马马虎虎，找村里的泥水匠也可以盖，大家都是这样造房子的，也从来没有听过需要请一个专门的设计师来盖房子。

如果你盖一间八层小楼，估计你不会找村里的泥水匠直接动工，你害怕，担忧他们盖的房子会塌了，村里面也从来没有八层这么高的楼，他们没有经验。

你开始托人打听外面哪里有高人，亲自把高人请来设计这个八层小楼怎么盖，地基怎么打，承重墙在哪，下水管道，主电路怎么铺设等，先做什么，后做什么，再做什么。

如果你盖一座100层楼高的大厦，你需要多久时间可以盖好呢，一层需要多个房间，哪些是办公区，哪些是洗手间，哪些是过道，哪些是梯，还要扛12级风，8级地震，保温效果要好，高层水压要好等等要求，你会怎么做？你会想，有一张图纸，那该多好啊！

软件架构是什么呢？

软件架构包含架构元素，架构元素之间的关系组成，输出架构设计文档，画多张架构视图，考虑相关的干系人，满足他们的关注点需求，在不同的阶段所画的架构视图不一样。

架构是提供给不同人看的，对内对外，对上对下不同人之间，能够沟通或指导等作用。

软件架构是顶层设计，是一张蓝图，一张高楼的施工设计图，它在不同时期，对不同人，可以细化，像一个洋葱，一层一层的可以剥开。

软件是设计出来的，小的系统不用设计，因为它就那些功能，就像草房，可能也只有一个人使用，也没有别的需求，如果要把草房改成一间砖瓦房，就要推翻从头来了，没有复用的基础。

当然真的是小的系统吗？有一张好的图纸，先进行设计一定会好得多。

让软件后续的功能扩展更有条理，迭代多个版本后还能对软件的功能一目了然，多人参与软件开发也不会混乱，可以分工明确。

把预期开发完成后的系统功能事先呈现出来，想像，经过思考设计出来，特别像室内装修的效果图，这个效果图就是你装修完房子后的样子，如果不漂亮，那就再改改设计方案。

3. 架构视图法

为了解决业务问题，建造模型，对业务领域的抽像与设计，以图形方式表达出来，方便与人沟通，达点解决问题目的。

就像你要建一栋大楼，可以先整一个电脑或实体模型，验证自已的想法，与相关人沟通是否满足需要，是否解决了问题。

架构视图表达方式有两种，一种为4+1视图，另外一种为UML建模。更建议使用UML建模，当然建模并不需要太严格符合UML的规范，建模的目的是为了沟通，为了解决业务问题。

4+1视图模型包括：逻辑视图，过程视图，物理视图，开发视图，场景视图。

UML统一建模语言常用的7种模型：静态模型有部署图，组件图，类图，用例图；动态模型有活动图，状态图，时序图。









软件设计一般要经过需求分析，概要设计，详细设计阶段，每个阶段的画的图不同，面对的群体也不尽相同。各个阶段的侧重要，粗细程度也不一样。

以终为始的设计方式，了解已知需求后，整理用例，想像成系统要部署了，先来一张部署图，划分一下系统与模块，有哪些子系统，子系统之间或是与相关中间件应用怎么通信，子系统内部的组件是什么关系，是否有交互...

组件图+时序图=组件层面的时序图，描述组件在业务场景条件下的交互（方法调用/远程通信）

类图有领域核心对象的类图设计



总的来说，软件就是设计出来，通过建模，在不同的开发阶段，画不同的图，给不同的人看，并且要让人得够看懂，通过图与相关干系人沟通，你也要能够说得明白，别人也听得懂，并且解决了他们的问题