架构师没有明确的定义，郭老师提出具备的能力：就是为一个复杂系统设计软件的能力，以及引导研发团队实施的能力。从5个 阶段来看对应的能力维度：结构化设计、解决横向问题、解决跨领域冲突、正确的技术决策和创造生存优势。

一结构化设计

   这个吧，我就是很惭愧，通常只要不给别人看，自己总是无比满意。如果后期经常做迭代，会发现之前写写的不太好，再去重构。结构化是一个结果，涉及很多方面，要做好不容易。

   代码抽象、OOP的设计思想

要求我们认真思考什么是类，什么是对象，什么是对象所具备的属性，什么是对象可能发生的行为，这个行为的作用对象是谁，等等。通过这种对模型本质的思考来定义软件结构，就是提升软件结构性设计能力的有效方法。

  如果单纯的写代码就是依照产品需求文档那就是从文字到计算机语音的转换，架构师的应该具备思维需要多思考，要这么具有前瞻性的设计吗？如果现在不需要，但是未来需要，我应该采取什么样的设计才能让未来的过渡最容易呢？这是基于对问题本质、商业价值和软件结构性思考的长远设计！

设计模式

  这个比较广泛 了，设计模式强调趋同性，用广泛传播的知识来标准化代码的实现，从而降低实现手段和命名的多样性，也就是提升代码的一致性，注意使用不当的 问题。

结构化设计过程关注点

   一 设计理念。整体设计需要与公司或部门的理念保持一致

    二 API 的结构性：

暴露给其他调用方的 API，要有条理、表达准确，且易于理解。

包含宏观的结构性，比如一个实体的 API 要反映出这个实体状态和行为。

功能组织上的结构性：一个 API 可能为多个用户角色服务，不同的用户角色和不同的使用场景，都应该有不同的设计粒度。

最后是数据模型的结构性。API 会暴露数据给调用方，那么暴露出来的数据就要有清晰的结构，遵守一定的规范。

  三  模块内部的结构性，也就是程序的结构性。

  比如Java的package、Interface、Class 和 function 实现的设计等。

如果个人与团队不太一致，可以尽量追求 API 的结构性，前提是不能与整个研发团队现有的设计规范相冲突。哪怕你认为现有规范不合理，也应该建议调整规范，因为这会影响他人代码的一致性和可读性，纯粹是私域的 代码除外。

二  解决横向问题

   横向问题，简单来说就是软件系统内部与业务无关的技术债，比如性能、可扩展性、可用性、可测试性、可维护性和安全合规等问题。

  从程序员成长为兼职架构师，需要跨越的主要的能力障碍就是责任边界，通常这种不属于某个研发人员具体的责任，应该优先吧日常开发工作做好，日常工作做不好，很快就被裁掉了，也做不了这个横向问题。

  从哪里开始呢？首先是 个人兴趣。其次考虑解决这个横向问题能给公司带来多大的价值？作为一个兼职架构师，最重要的价值就是帮助团队中被某个横向难题挡住的程序员清理路障。

    可以先从 稳定性解决，毕竟自身收益，报警少了压力也少。这个不需要额外授权，跟工作连续性大。这个话题很大，郭老师给了相关的一些建议：

1 从来都不要相信自己的代码是在一个可靠的环境中运行，任何时候都要坚持检测你的依赖方。

2  系统的可用性会随着复杂度的提升而降低。如果想设计一个高可用系统，就必须把依赖最小化。如果是被迫引入依赖的话，就要选择最靠谱的人和最靠谱的模块。

3  所有东西都会过期变质，尤其是数据。有时候不是简单回滚就能解决问题，可能数据配置不匹配造成数据污染，也就是在设计中要考虑数据污染的情形。

4 在可用性面前，所有依赖都可以被降级。也就是通过大量的压测和充足的预案，保障重大活动高可用性。

5 不考虑成本的稳定性就是耍流氓。要考虑成本 。

6 保护自己：当故障发生的时候，首先要想方设法地恢复自己所负责的服务，不要等待强依赖方的恢复。

降级、限流、监控、报警等稳定性常规手段，在多数互联网公司都已经齐备。手段还不算原则。

除了稳定性，性能也是与 商业回报有关的额高优先级。

    横向问题不是越多越好，公司发展到一定规模后相比覆盖广度，横向能力的深度和稀缺性要更重要一些。

 三 解决跨领域冲突的能力

     上节学了从程序员到兼职架构师的跨越，也就是如何搭建解决横向问题的能力。 在兼职架构师这个角色中，架构能力是一个加分项，写代码实现需求仍然是主要工作。

      从兼职架构师成为跨域架构师，需要完成从一对一关系到一对多关系的跨越。这个校色转变很大，跨域架构师对多个领域的软件架构间接负责，只能通过各领域的研发管理者来间接影响自己所负责的领域架构。

      在多个领域的软件架构，而每个领域都有对应的研发经理，甚至领域内还有对应的兼职架构师，这些领域之间的设计理念等肯定不一致。这些领域有各自的领域目标、领域挑战、需求优先级和相对独立的工作环境。因此跨领域架构师要持续抵抗天然的熵增，将多个子领域中不同的设计理念、代码结构和实现方式，往同质的方向上进行整合。是大型组织的需要。    

  对比一下兼职架构师，这个角色只需要关注自己领域或模块的架构问题就行了，解决的还是内部技术债的问题，不需要化解多个团队之间的冲突。跨域架构师对这些领域没有管理控制权。每个领域的大佬都有各自的理念和行事方法，不但互相之间有矛盾，好比你之前代码写的再好也不能把别人推开自己去改代码。现在只能靠驱动他人来作出正确的判断，才能让想法变成现实。

郭老师给了一个常见的背锅场景。一个交易域的跨域架构师对接三个独立团队负责交易、支付和资金领域的开发。

产生的跨领域问题本质： 领域割裂、决策割裂、执行割裂、沟通割裂

从全局视角做架构干预

跨域架构师的存在就是协调子域之间的决策、执行和沟通，从而平衡全局结构化和局部个性化之间的冲突，最终最大化全局目标的实现。

   再各个子域互相沟通的情况下，这不是说架构师没用了，架构师的专业会让大家少走技术弯路，因为你要靠真实可靠的技术论据和完美的逻辑来说服大家采用正确的判断。技术能力同样有价值。

高速发展的公司里，往往还有合规、审计、风控和安全等其他维度的问题被各团队忽视了，这类问题的共性，可以统一归结为之前局部最优的架构决策在全局视角下不再最优。此类决策都是跨域架构师的核心增值所在。

  到这里，理解一个跨领域架构师如何突破局部视角的障碍了：

  1.理解整个全局领域的目标。

2.最大程度地熟悉每个子领域，理解每个子领域的目标、挑战和需求的差异性。

3 围绕统一的目标去分析局部视角上的差异性，引导各个决策者和执行团队从全局视角上看问题，最终引导多个子域在目标和全局目标上形成对齐。

4.设计公开的沟通机制，促进子域之间的信息对称，使得每个决策者和执行者能够看到全局的优化目标，以及其他团队的重大决策、执行方式和当前状态。

5.逐步解决具体的设计理念、代码结构实现方式的冲突，达到全局最优。

而类似多个团队之间的判责，你可以引入这样一个思考实验：如果没有三个团队，只有一个具备超级大脑的人实现了整个系统，那么他是在什么阶段引入了这个故障呢？从整体视角去看，

跨域架构师千万不能充当和事佬，能力可以训练或者失败后修正来弥补，勇气是主要的。需要有足够的勇气去发现、面对和解决这些冲突。解决冲突的过程，也就是兼职架构师创造增值的过程，持续做好这件事，就能跨过从兼职到跨域架构师的最大障碍了。

   四 正确的技术决策和创造生存优势

总架这块我就是看看，体会不到这么高。认知达不到。

 看看郭老师说总架是如何思考和决策的。

  核心能力做正确的技术决策，也就是说，总架构师要为整个公司软件架构的正确性负责。其实是面向未来的技术不确定性下的外部适应性。不像是技术债跟 明确的去除局部架构缺陷，面向未来的架构正确性几乎永远没有明确的答案。技术发展、技术人才供给、商业竞争都有非常大的不连续性和不确定性。

    总架构师这种正确决策的能力，常常被叫作技术嗅觉。不断寻找高风险决策的机会来提升技术嗅觉。

你在帮助他人做高风险决策时，要做的事情就是：

1.理解整个决策的背景。

2.理解决策的制约因素。

3.在你所精通的领域提供尽可能多的依据，在最大程度上降低小决策的不确定性。

4.从你所精通的领域出发，为最终决策做出建议（也就是拍个板）。

5.尽可能多的参与到决策讨论中，了解其他领域的不确定性和收敛方法。

6.无论最终决策是否与你的建议一致，都要尽可能地理解最终决策背后的逻辑。之后的数月甚至是数年，持续关注决策的后续进展，反思自己提供的决策建议中那些缺失和误判的部分。

7.之后的数月甚至是数年，关注其他领域后续的变化，思考最终决策的正确性。注意，不仅要看最终效果，还要看判断决策逻辑和过程的对错。

CTO更高了，CTO 的商业嗅觉更重要。技术不是 CTO 决策的第一优先级，在技术之外寻找解决办法的思维。

对人才的判断力是任何一个管理者最重要的能力。能够相信、尊重、容忍与你不一致的判断，而且能够在他判断失误的情况下，帮助他提升，给他再次决策的机会。这才是一个了不起的管理者。

五 架构师成长的必要条件

  简单回顾下，这五个角色在架构师成长的五个阶段。1.在程序员阶段，主要关注需求实现的结构化，也就是一个模块内有关业务的部分。2.兼职架构师阶段，主要关注模块整体，以及与业务无关的横向问题。3.跨域架构师阶段，主要关注不同模块间结构合理性的问题。4.总架构师阶段，关注技术架构的长期正确性。5.CTO 阶段，关注企业的长期生存。

想培养出这五个维度的能力，需要具备什么必要条件呢？

一 独立思考的能力：通过独立思考带来有效结论的能力。 

独立指1.有别于其他人的视角；2.不同的证据组合；3.不同的思维方式。

其次是“有效”，也就是为公司或团队带来足够的价值。

  现在当我们面临的问题，会找到多个答案，难得是甄别多个答案优劣的能力 。

二 信息内化能力：

  信息内化的过程，也就是从接触信息到消化吸收成个人知识的过程。

 在当前高度竞争的环境下，缺少信息优势，很难在架构师的成长过程中胜出。我们需要深度理解自己所在企业和行业的特点，找到自己的特定信息优势，并最大程度地内化这些信息来获取成长。

三：适应力

 从程序员到架构师再到 CTO 的职业成长阶段，与其他职业相比有个重大的差异，那就是能力的不连续性。岗位技能、个人技能、管理技能等需要时间、经验和机会磨练出来。

其他通用技能想自驱力、学习、沟通、推动等，也需要，软件行业内卷的情况下，没有特别突出。这里又有个取舍，要专注于少量必需的条件上。

    看行业猎头发的跟大厂高P聊天，即要站队抱紧老大大腿，又要去竞争做出业绩来。这种高P就不是纯粹的技术，要有非技术的敏感度。机遇很重要，情商也要很高这些虽然老师没讲，但是也得明白。

  六  架构师成长的充分条件

不满足必要条件，就做不了架构师。还需要充分条件：

一 大量的高风险的决策机会：

一个激烈竞争赛道中的成长型的中小公司，往往有大量高风险的架构决策机会。

二 对架构师友善的环境：

1.相对宽裕的决策时间；2.对架构师意见的尊重；3.对错误决策有足够的包容度。

 考核、排期等决策容易看出来。

三  正确的目标

  工作环境能够一直维持正确的目标。这样的目标在定义中就公开透明，鼓励全员参与；在决策中尊重数据和事实输入，有确定的 KPI 和数据结果来衡量产出；在最终的复盘中，不忌讳失败，会认真反思分析。

这些充分条件就是外部给予的成长环境，这里郭老师引用了机器学习这个学科分支的基础假设，如果把架构师想象成一个大数据驱动的算法模型，那么架构师的成长，就是这个模型在不同场景下快速找到正确架构设计的过程。那么最终的产出是什么呢？对于机器学习系统而言，就是高质量的算法模型。对于架构师而言，就是最优的架构设计。充分条件保证了成长的有效性，必要条件保障了成长的速度。

  职业选择：

   选择行业要比选择企业更重要！寻找高速成长的企业，这个选择肯定是有风险的，如果从不为自己的决策担风险，就无法获得复杂、竞争的商业的成功。

小结：

  回顾这个模块，郭老师都在讲每个层级的目标是要解决什么问题？需要什么能力维度？再分析：现有能力 需要跨越的障碍是什么？最终 你的回报是能力的提升。这里有个隐含的条件，就是成长的意愿。