第 0 周学习总结

day1:

1.架构并不是什么阳春白雪的东西，架构是来源于工作上的安排。

2.在公司里成为架构师了以后才能做架构，要为整个系统负责，做架构的事就是架构师。

3.产入和产出，怎样将自己的架构呈现给别人看，架构师的主要目的就是将自己的架构思想具体成真正的产出。

4.如何定义问题，和解决问题，并证明问题已经被解决了。

5.团队内部在沟通中需要确定：对方诉求，利益相关方诉求，双方的边界和职责，利益诉求能否达成一致。

6.让自己的架构满足更多的利益诉求，让更多的人接受自己的架构。要在解决问题的过程中不断的迭代，反思，优化自己的架构，而不是一味的拒绝别人的意见，尽量的协调和统一各方的利益诉求。

7.架构最主要是思想，不要太拘泥于具体的技术。技术是工具，重要但不应当过于在意到具体实现，能落地的架构才有成为好架构的基础。能将架构实现的技术对于自己的架构来说就是好架构。并没有什么标准答案。

8.要对自己面对的问题，需求，背景进行深入地思考，并最终提出自己的解决方案。

9.架构需要将组件间的交互关系表达清楚，并在架构过程中把握住关键点，防止复杂性的扩散。

10.相关方是架构设计中最关键的点，需要对不同的相关方呈现出不同的架构文档。

11.架构虽然有方法，但也是一件很主观的事，架构一定是基于场景的。

day2:

架构之前架构师就要建模，建模是为了验证模型是否能工作，并方便与他人沟通。建模是架构师架构思维的具体体现。

12.模型是完整系统的抽象，系统的关系是存在于现实之中的，必须要和现实贴近，不然会导致后期的开发出现问题。

13.UML 画图好坏没那么重要，关键在于利用 UML，可以让彼此能够交流起来。

14.UML 必须记住的 7 种模型：

静态图：用例图，类图，组件图，部署图；

动态图：序列图，活动图，状态图。（其中协作图可以由时序图生成）

15.依赖，关联，继承，实现，组合，聚合。

依赖：弱关系，类似于方法中的形参。

关联：稍强于依赖，类似于成员变量。

组合：生命周期一致；

聚合：各个组成部分可以独立存在。

16.用例图在需求分析的时候使用，设计功能-功能，功能-使用者之间的关系；

17.三个阶段：需求分析文档（系统要做什么，大体功能，要求约束），概要设计文档（高层架构，部署，功能模块，系统流程），详细设计文档（类图，类之间的关系）

18.一切文档要到哪一步，关键是要确定文档是给谁看。

19.对象间的消息就是方法调用，都是同步消息。

20.异步消息是服务器或组件间的调用，在处理完后主动发消息给调用方。

21.活动图是对象间的调用关系，活动图在所有阶段都可以使用。

22.状态图表示不同状态间的迁移状态关系，在文字描述过于复杂时，可以让想表达的逻辑更直观的展现。（需求分析，详细设计）

23.组件图，是设计中最重要的一个图，设计多大，为什么要这样设计组件。

24.部署图，物理部署，部署到哪些服务器（现有，新的）

25.组件设计分配时，要根据现实中设计组件的两个人间的关系进行分配。

26.架构师一般负责概要设计和详细设计，第一个要有的是部署图。