备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~
好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神。 对应技术是“高内聚、松耦合”、“单一职责原则”、“接口隔离原则”。
如果一名架构师存在职业发展瓶颈，那么他的问题大概率是简单的设计方法没有执行好，而不是复杂的设计方法没学会。
- OMS（订单管理系统）： 处理用户订单，负责调度
- WMS（仓库管理系统）：负责仓储管理
- TMS（运输管理系统）：安排物流运输。
“V” 字型设计
拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。
从零实现一个淘宝网拆分成：
订单中心，用户中心，商品中心，库存中心
订单中心还可以再拆分：
订单创建，订单查询，订单履约
不断继续拆分，直到能够用简洁优雅的代码去实现。
合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。
比如订单创建、订单查询都需要对数据库进行操作，那么与数据库的交互就应该统一封装。
架构是由元素（element）和关系（relationship）组成的。
- 「元素」：稳定、可复用的部分应该变成组件或应用模块，对应着架构中的
- 「关系」：不确定性的设计，则需要变成协作方式，为可能的扩展作准备
架构师的基础与核心能力：「专业分工」和「协作精神」
微服务基本的原则：让系统的分工更明确、责任更清晰。
中台：突出了“可重用部分的抽象”
中台是一种企业级的架构理念和方法论，侧重于业务能力的沉淀和复用；
微服务是一种软件架构风格，侧重于服务的拆分和独立部署。中台可以基于微服务架构来实现。
无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。
架构设计本质上是一种“中庸思想”，如果单纯考虑功能设计，我们的目标只有一个：让架构响应业务调整的速度更快。
保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来。
复杂架构设计如何落地执行
- 关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
- 架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
- 人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
- 同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素 / 职责超过 10 个，就要进行拆分；
-元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件； - 如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
- 那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用 SOA 架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用 EDA 架构；
- 在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
将复杂问题拆解为简单问题，逐一解决再合并，并将可复用的知识抽象，以实现举一反三。
