架构学习心得：系统架构-复杂系统的产品设计与开发

CSDN话题挑战赛第2期
参赛话题：学习笔记

学习之路，长路漫漫，写学习笔记的过程就是把知识讲给自己听的过程。这个过程中，我们去记录思考的过程，便于日后复习，梳理自己的思路。学习之乐，独乐乐，不如众乐乐，把知识讲给更多的人听，何乐而不为呢?

系统架构-复杂系统的产品设计与开发-学习心得
1、帮助形成“思考并创建系统”的架构思维
2、管理系统复杂度，优化生产成本，赢得竞争先机
3、23项架构原则，助力系统架构的创建

1、学习笔记-本书框架

        技术始终是为业务服务的，能解决问题、产生业务价值的技术都是有意义的。但我们有理由追求更高、更快、更强，架构方面一样有理论知识来指引我们实现目标。

        架构师不能脱离业务，因为要创造业务价值。        

        架构师的职责之一，在于管理系统复杂度，目标就是降低系统复杂度，达到目标的策略就是分解。由此引发出架构的硬技能：用什么知识+选什么工具+坚持什么原则。《系统架构-复杂系统的产品设计与开发》就是一本理论扎实的一手知识。

一手知识：知识经得起时间的考验，引发读者共鸣与思考，持续产生价值。

特性：内容少而精（但需要读者去参透）、保值时间长。

例子1：医生、律师、艺术家等行业，不用担心失业问题，因为掌握的是一手知识，且需求大。

例子2：开发者等，经常担心被技术革新革掉出路，经常担心，因为掌握的是多手知识（每年总会产生比去年更好用、更简单、更吸引人的新框架）。

本书知识结构如下：

​​​​​​​

2、架构师能力模型

        由此可看到架构师应具备的能力。

什么是软件架构

        软件架构是一个系统的基础组织。包含组件，他们之间的关系以及与周边的关系，设计原则，以及系统演进。

架构的级别

应用级别（Application Level）: 架构最下层级别（lowest level）。只关注一个单一的应用。非常的关注细节，关注底层设计（ Very detailed, low level design）。沟通往往只限于开发团队内部。 

解决方案级别（Solution Level）: 架构的中间级别（mid-level）。关注的是一个或多个应用，从而满足某个业务需求 (业务解决方案)。有点高，但主要还是low-level设计。沟通跨多个开发团队。

企业级别（Enterprise Level）: 架构最高级别。关注多个解决方案（solution）。高级（High level）, 抽象设计（abstract design）, 需要总览全局，总览多个解决方案和多个应用架构师。沟通横跨整个组织。

有时候，架构师也被戏称为“胶水（粘合剂）”，不同利益相关者之间的胶水，举三个例子：

水平: 业务、开发人员或不同开发团队之间的沟通桥梁。

垂直: 开发人员和管理人员之间的沟通桥梁。

技术: 不同技术或项目（产品）之间的集成桥梁。

什么是架构师

        软件架构师是一个软件专家，技术上：负责做出高阶设计选择和输出技术标准，包括软件编码标准、工具和平台（框架）；业务上：承上（业务）启下（技术），减少歧义和复杂度。

软件架构师要做的几个典型活动

• 确定和决定要使用的开发技术和平台。
• 定义开发标准。比如，编码标准，工具，代码review流程，测试方法等。
• 协助识别和理清业务需求。
• 设计系统和基于需求做出决策。
• 记录和沟通架构定义、设计和决策（Document and communicate architectural definitions, design and decisions）。
• 检查和review架构和代码。比如，检查确定的模式和编码标准的实现是否合理。
• 与其他的架构师和利益相关者协作。
• 开发人员的教练和顾问。
• 细化并把high level的设计具体到low level设计。

3、在线资料

如何做架构设计和评审：如何做架构设计和评审

阿里技术大牛：一份架构师成神路线图！：阿里技术大牛：一份架构师成神路线图！

如何画好一张架构图？：如何画好一张架构图？

架构师必备的37项技能清单：架构师必备的37项技能清单