摘要
这是一篇架构师思考方法论的学习笔记，原文对什么是架构，什么是架构师，架构师如何定义和分析问题进行了比较深刻的探究。
一，什么是架构
架构的三要素：
- 职责明确的模块或者组件
- 组件间明确的关联关系
- 约束和指导原则
三要素是关于架构这个名词通用的定义，不局限于软件开发领域。下面具两个例子便于理解：
例1：软件架构
- 模块：模型、域
- 关系：一对一、一对多（模型）；依赖（域）
- 原则：单一职责、开闭原则、里氏替换原则等等
例2：组织架构
- 模块：部门
- 关系：管理 or 上报
- 原则：各种管理原则、财务原则
下面我们具体讨论的还是软件开发中的架构。
二，什么是架构师
架构师这个角色的职责是：识别并定义问题，创建、选择或调整架构，从而找到最优的方案，解决问题。
这其实也是架构师做事的一般套路：定义问题->确定架构->提出方案->落地拿结果。这四步中，越是前面的步骤，越是重要，越是抽象，也越是困难，越能体现架构师的功力。因此有必要探讨下问题的本质。
1， 什么是问题
问题就是事物的矛盾。哪里有没有解决的矛盾，哪里就有问题。——毛泽东
架构师要定义和解决的问题，就是特定领域中的矛盾，解决了矛盾，就得到了发展，取得了收益
2， 区分问题、手段和挑战
问题和手段经常被混淆在一起，其实这三个概念可以看做矛盾的不同层次。
每一个问题可以向下不断展开不断细化，下一级的问题是上一级问题的具体解决手段，当你把“提升性能”当做你Owner的问题时，提升帧率、提高页面秒开率、优化启动耗时就成为了你的具体解决手段；而手段的下一级问题，就是你将面临的挑战，比如你要优化网络耗时，你要面临的挑战就有弱网环境、一些国家区域的带宽问题等等。
3，如何定义问题
亨利福特说，如果我问客户需要什么，他们会告诉我，他们需要一匹更快的马。
定义问题经常需要思考问题背后的问题，为什么客户需要一匹更快的马？可能客户想要更快的日常交通方式，上升了一个层次后，我们立刻找到了更好的解决方案：造车。
当然当我们无法准确的分辨问题的时候，我们还可以不断缩短描述问题句子，比如提炼主谓宾，如果还不能清晰的描述那么在这几个词里再找出最最最关键的词，尤其是主语或者宾语中的词汇非常重要，它有可能就是重点，只是我们无情的忽略它了。
后面两节，介绍架构师工作中要弄清的概念，帮助大家在和不同职位的人沟通时提升效率。
三，架构的分类
和业务需求方、产品经理、技术设计聊天，他们都会提到架构，但他们口中的架构不是一回事。区分清楚工作中常用的架构分类，可以让你在开会时把不同职位的人口中的架构对号入座，以提升沟通效率。
| 名称 | 受众 | 目的 | 内容 |
|---|---|---|---|
| 产品功能架构 | 产品使用者，产品经理 | 指导用户，吸引用户 | 从用户角度，阐述产品功能模块 |
| 业务能力架构 | 研发人员，业务人员 | 用于理解业务内在的概念和联系,有助于我们分析和理解业务需求 | 业务能力，能力中的子能力 |
| 应用逻辑架构 | 研发人员，架构师，技术管理者 | 指导软件研发 | 阐述架构中各模块的职责：如系统模型，技术模块，技术模块的关系，技术模块的核心抽象，如何用设计模式来让架构符合软件设计原则，等等 |
| 应用物理（部署）架构 | 运维人员，架构师，技术管理者 | 指导运维部署软件 | 逻辑架构如何落地，比如使用何种微服务容器，逻辑架构的模块落地时应该是package，还是应用，是不是要跨机房部署等等 |
| 基础设施架构 | 架构师，技术管理者 | – | 选择什么样的中间件，存储，监控等等 |
四，能力和职责的区别
产品同学一般讲能力，而架构同学一般讲职责，区别如下：
能力
指一个产品能做什么，如中台本身是一个产品，对使用中台的人来说，我们应该讲中台的能力。
职责
指架构内模块的职责，用来指导开发。比如对中台的研发，应该讲架构的职责，依赖，约束。
简答来说，能力是对产品的使用者来说的，职责是对架构的实现者说的。