18 架构设计，专业分工和协作精神的体现
你好，我是乔新亮。今天，我想和你聊聊，关于架构设计的一些认知和体会。
作为技术人，最常接触的概念，恐怕就是架构设计了。即便是初出茅庐的新手程序员，可能也听说过 6 大设计原则与 23 种设计模式。因为，要成为管理者或技术专家，架构设计绝对是你绕不开的槛。
因此，关于架构设计的书和课程非常多，多到简直学不完。如果用我们专栏文章的形式来讲，写出一百篇文章都不为过。
但在今天，我们只聊一点认知，我认为，也是架构设计最核心的认知：好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神。
认知讲完了，是不是感觉有些熟悉？
没错，其实在很多架构设计思想里，我们都能找到这句话的影子，比如“高内聚、松耦合”、“单一职责原则”、“接口隔离原则”，太多了。
你可能会想，老乔坑人呢，作为一个 CTO ，在架构设计这一讲，就交付了一个这么基础的概念。
没错，这个概念确实很基础，但我想告诉你，其实架构设计，尤其是业务/应用架构的设计，原本就没有那么复杂。
工作了近 20 年后，我发现，如果一名架构师存在职业发展瓶颈，那么他的问题大概率是简单的设计方法没有执行好，而不是复杂的设计方法没学会。
复杂的学会了，简单的却没做好，听起来很奇怪吧？下面，我们详细聊聊，这究竟是怎么一回事。
从程序员到架构师，什么能力在提升？
2020年，刚到彩食鲜的时候，我去审查团队技术需求的分配和实现，发现了一些不合常理的情况：对于部分业务流程改造工作，我认为很容易实现，团队却需要花费大量的时间才能落地。几天就能改好的代码，花掉一个月的时间都是有可能的。
有时，团队甚至会觉得，单是为了实现需求，就已经很吃力了，从整体的逻辑上看就很不合理。
仔细一查，我才发现问题的根源所在：表面上看，是逻辑不合理，实际上是架构设计不合理。
生鲜/电商类业务的架构一般会包括 OMS（订单管理系统）、WMS（仓库管理系统）、TMS（运输管理系统）等系统。其中 OMS 处理用户订单，负责调度；WMS 负责仓储管理；TMS 负责安排物流运输。可以看到，其实功能的划分很明确。
但很多业务在研发迭代时，并没有做过架构方面的考量，比如将与订单相关的逻辑直接放在 WMS 处理了：WMS 接到 1000 斤蔬菜的订单，检测仓库内只有 500 斤，于是发送请求到采购系统，要求再采购500 斤回来，然后将订单交付。
这样的逻辑能保证功能实现吗？当然可以，但长远看来，就会出现架构层面的设计问题 —— WMS 越来越臃肿，最终导致新需求的处理速度严重下降，影响业务的增长，这就是很多企业正在为之头疼的现实。
你可能会想，这个例子里的架构师真傻，连 OMS 都不知道。
真的是这样吗？事实上，类似的错误，很多企业每天都在犯，尤其是 IT 服务于自身生态的甲方企业。大家习惯于基于业务需求写代码，而不是基于架构设计写代码，反正来了需求先实现了再说，尤其是在业务刚刚起步时。
比如，在业界，你会发现一个很普遍的现象：许多企业投入大量的资金和人力进行 IT 建设，但每隔几年就要进行一次架构上的大调整，甚至直接推翻重写。
大部分人甚至已经习惯了这种行为，觉得重建很正常，而且是一名架构师能力的证明。
事实上，如果架构师严格按照“专业分工、充分协作”的思想去迭代需求，这样的重建根本就不应该出现。一名优秀的架构师应该像个“隐形人”，似乎什么都没干，但其负责的架构就是能快速响应业务的需求。
什么叫做“快速响应业务的需求”？就是说，在同样的业务复杂度下，在系统建设的不同阶段，可以使用相近的工作量完成需求。
那么，所谓的“专业分工、充分协作”，到底是做了什么呢？回到架构设计实践里，无非是一个先拆分再合并的 “V” 字型设计过程。
拆分是指将一个负责的功能按角色、按职责拆分，核心特征是单一模块的功能既单纯又简单。比如，要从零实现一个淘宝网，是相当复杂的事。但我们可以将其拆分成订单中心、用户中心、商品中心、库存中心等许多模块；订单中心还可以再拆分，比如拆分成订单创建、订单查询、订单履约等功能；如果实现仍然复杂，我们还可以继续拆分，直到能够用简洁优雅的代码去实现。
合并是指将类似的职责放在一个模块完成，抽象出可重用、复用的部分，提升业务响应效率。比如订单创建、订单查询都需要对数据库进行操作，那么与数据库的交互就应该统一封装。
抽象地看，架构是由元素（element）和关系（relationship）组成的。在架构设计中，那些稳定、可复用的部分应该变成组件或应用模块，对应着架构中的「元素」；而面向不确定性的设计，则需要变成协作方式，为可能的扩展作准备，对应着架构中的「关系」。
这就像一个足球队，有人司职前锋、有人司职中场、有人司职中后卫，分工明确才能组成一个有战斗力的队伍；中场可能回撤参与防守，后卫也可能前插参与进攻，这样才能对可能的变化作出响应。
如果什么设计都没有，就只能变成一群追着球玩的小孩。
那么「元素」是拆分得越细越好吗？当然也不是，5 个模块能搞定的功能，你非要写 100 个模块，只能是给自己徒增烦恼。
所以，从初级架构师到高级架构师，什么能力是一直存在并持续提升的？其实就是对复杂业务的拆分能力、对可复用部分的抽象能力、对拆分过程的颗粒度把握，以及对未来变化的考量和设计。如何让架构有足够的“应变能力”，则与架构师对业务的理解程度息息相关。
如果用一句话总结，那就是：对架构层面的「专业分工」和「协作精神」的理解，是一名架构师的基础与核心能力。
认知延伸：如何看待微服务和中台架构
你可能会想，老乔讲的对是对，可有什么用呢？
别急，我们通过前面讲的架构设计思想，反过来看看近几年大火的微服务和中台架构。
关于微服务，首先我们要知道，它的功能和数据处理是封装在一起的，这和 SOA 架构非常类似；其次，服务交互、服务治理、服务监控、服务隔离等很多基础性能力已经封装在框架中，可以让开发团队聚焦在功能实现上；再者，通过和 Kubernetes 集成，微服务的功能、数据、基础设施被再次封装，技术架构也再次进行了升级。
看得出来，在微服务框架下，技术架构部分的很多职责已经被抽象出来，并对框架进行了处理，隐含着相关理念的最佳实践。
同时，微服务也有一个很基本的原则：让系统的分工更明确、责任更清晰。所以你看，还是我们上面讲的那些内容。
对于业务侧架构师来说，即便是使用了微服务架构，工作还是会集中在架构设计方面，比如：业务功能如何进行归类。具体到微服务改造的过程中，就会碰见一个典型问题：微服务拆分的颗粒度怎么把控？微服务，英文 MicroService，划分粒度一定要很细吧？
其实这个问题压根没有统一答案，为什么？因为我们前面讲过了，即便没有微服务，架构师也要做功能的拆分，至于对颗粒度的把握，既受业务本身的特性影响，也受架构师的能力影响。
换句话说，一名对架构的“分工”和“协作”理解得足够好的架构师，很少会困惑于微服务拆分的颗粒度问题。因为从本质上来讲，这些都是一码事。从单体应用到各功能独立服务，其实是处于功能拆分的两个极端，但架构设计本质上是一种“中庸思想”，如果单纯考虑功能设计，我们的目标只有一个：让架构响应业务调整的速度更快。
那么架构如何才能实现更快的响应速度呢？就是在保证各「元素」职责清晰的情况下，抽象出稳定的功能或组件，用业务流程去串联起来。在一定时期内，一家企业的技术架构的功能或者组件基本是稳定的，而业务如何运转，却是动态变化的，甚至每周都在变。可以说，以不变应万变是架构设计的精髓。
这个设计思想又和中台架构如出一辙。企业搭建中台，最重要的目标之一，就是实现企业营收层面的“开源”，承担企业架构快速响应市场需求的任务。其关键词包括：消除烟囱、架构解耦、统一中台、服务重用……
没错，和我们前面谈的架构设计核心思想又是基本一致的。
关于中台，业界很多技术人都踩了不少坑。刚开始听说中台概念的时候，大家一拥而上，做得多了才发现，中台到处都是坑。以至于在当下，许多人对中台是嗤之以鼻的。
为什么呢？我认为很重要的一个原因，是大家忘了架构设计的“初心”，错认为中台是个全新的设计理念。
其实从架构的视角看，中台这个概念并不新鲜，它只是突出了“可重用部分的抽象”这部分工作。那么， 如果你的 IT 系统可复用部分不多、业务量不高，建设中台的意义何在呢？如果你的中台对业务没有帮助，建设中台的价值如何体现呢？
你看，时刻牢记架构设计的核心原则，能帮助我们更清晰、更透彻地看待当下的许多“时髦理念”。
当然，这里可不是说，中台的兴起，就是一群不专业人士的狂欢，绝对不是这样的。苏宁在 2012 年就开始中台建设，2013 年上半年完成。后来在利用中台接入天猫业务时，团队仅花了七天七夜的时间就完成了融合，速度非常之快。
关于企业数字化转型、中台建设，我在公众号里，曾经分享过一个系列，共 9 篇文章，用大概 4 万字左右的篇幅，描述了一个关于中台的“指挥官体系”，大家可以读一读，理解下中台和微服务设计的具体内容。
所以，无论是微服务还是中台，都有其巨大的实践价值，但二者只是架构设计核心原则的一种成熟的实践模式和承载方式，不是解决架构问题的“灵丹妙药”。
简单来说，如果你能按照架构设计的核心原则，做好模块拆分，那么微服务架构可以非常好地承载这种设计思想，为你提供服务治理、监控等一系列工具。但如果你在架构设计层面就做不好拆分，微服务也不能直接帮你解决颗粒度问题。
如果你问我，老乔，我没有“专业分工”的设计意识，也做不好功能的拆分，是不是用了微服务就搞定了？我只能回答，怎么可能呢？天底下没有这样的美事。
复杂架构设计如何落地执行
下面我们再来聊聊，复杂的架构设计究竟是如何落地的。
在 IBM 工作的那段时间，我曾经内部分享过一门专业架构师培训课程，包括为期 5 天的 Enterprise Architecture（企业架构）培训课程、为期 3 天的 Architecture Thinking （架构思维）培训课程、为期 3 天的 Component Modeling（组件建模）培训课程，以及为期 3 天的Operation Modeling （运营建模）培训课程。
我尽量用最简单的方式，将功能性架构设计中，最简单直接的方法和步骤抽象总结出来，分享给你，其中也包含了少数我们上面提到的内容。
- 关键认知：在个人视角里，整个世界都可以按照确定性内容和不确定性内容做简单区分；
- 架构将其抽象为元素和关系，元素对应着确定性内容的处理，是看待这个世界的稳定视角；关系对应着不确定性内容的处理，是看待这个世界的响应视角；
- 人类的理解能力有限。包含内容过多的元素，会导致理解困难，需要将其拆分；
- 同理，将元素归类的时候，也不能贪多，不然会导致理解困难。优秀的架构师，会将合理数量的元素进行归类，归类后的整体一般被称作 component 或 module，也可以直译为“组件”。比如，我们永远以“元素数量为 10 ”作为一个衡量点，只要一个组件包含的元素/职责超过10个，就要进行拆分；
- 元素归类一般采用 “V” 字型分析法，即流程分解为功能，功能聚合为组件；
- 如果组件明确了，意味着职责就建设好了，架构的元素（element）建设问题就解决了。组件对外暴露的能力，我们统一称之为服务；
- 那么，架构的关系（relationship）建设问题该如何解决呢？稳定的关系，用来表达确定性的交互，使用 SOA 架构，做好服务调用就可以；不稳定的关系，用来表达不确定性的交互，使用 EDA 架构；
- 在每一个新需求到来时，尤其是大版本的更迭，架构师需要介入产品经理和程序员的沟通中，判断新需求是否大幅增加了某些组件的复杂度，并决定是否调整组件职责，或对现有组件进行拆分。所以，从实际的业务发展来看，组件的数量是逐步增长的，如果一开始就很多，基本属于过度设计；如果业务复杂度已经翻倍了，组件数量却没变，基本属于缺乏设计。
那么以上就是落地复杂架构设计时的一些关键认知，要结合前文的阐述，多多体会。如果有疑惑，欢迎留言提问。
结语
今天我们聊了聊架构设计的核心理念：专业分工和协作精神，具体来讲，就是做好功能的拆分，抽象其中可复用的部分，并保留面向未来的扩展空间。
这里我们聊的仅限于功能型架构的设计，关于高性能、高可用、高并发、风险控制等非功能型架构设计，我们将在后续内容里逐渐展开。
我猜，即便看到这里 —— 这一讲的结尾，你可能仍然会想：这个理念是不是太简单了。
其实很多知识恰恰是这样：说简单也简单 —— 容易理解，也容易操作；说难也难 —— 即便是首席架构师、技术总监，可能也还是会被类似的问题困扰，重复犯类似的设计错误。
究其本质，在于我们要用发展的眼光，看待个人成长、架构设计这类相对宏伟的命题。就像我常常说的，要做时间的朋友。
做架构设计的同学都知道，罗马不是一天建成的。同样，对架构设计核心原则的理解，也不可能在一年、两年内达到满分，这种理解往往会随着技术人的成长而持续加深。
其实，人类在解决很多复杂问题时，都会采用类似的思维流程：将复杂问题拆解为简单问题，逐一解决再合并，并将可复用的知识抽象，以实现举一反三。我们今天所聊的架构设计，其实就是这种思想在软件设计层面的复现。
希望你也能将这个看似简单、实则复杂的知识点吃透、嚼烂，最终做到返璞归真，成为一个优秀的架构师或技术管理者。
我们下一讲再见。
- :) 👍（30） 💬（2）
架构设计的终极目的： 快速响应业务需求，对业务达到可持续的稳定的支撑！ 为了达到上述的目的，不同的时间，不同的地点，不同的环境，不同的发展阶段，都可能有不同的解决方案措施，但是别问白猫黑猫，抓到老鼠就是好猫。 之所以有各种各样的架构，很大程度是为了应对"复杂性"， 如果事情本身不复杂，为了架构而架构，就是舍本逐末。而影响到事物复杂性的因素主要有：事物数量多，事物联系多，事物变化多。为了解决复杂性，我们就应该 化繁为简。然而，事物的复杂性永远不会消失只会转移。将事物划分的过粗，可能导致单个模块内部过于复杂;而将模块划分的过细，导致整体的模块的数量过多，以及潜在的联系过多。所以要把握一个度，这个度的标准就是"高内聚，低耦合"。为了应对复杂度中"变化多"的因素，我们应该从业务发展的角度来看，哪些部分是稳定的，哪些部分又是将来可能发生变化的，将变化的部分是否可以抽象出不变的框架，作为扩展点。
2020-12-04 - 谷常生 👍（12） 💬（1）
《闪电式扩张》中把企业分成五个阶段：家庭、部落、村庄、城市、国家。架构债务，其中一个原因是组织已经发展到了城市或国家阶段，但是系统还停留在部落甚至家庭阶段。 康威定律也指出，组织架构和系统架构之间有一种隐含的映射关系。组织，需要分工和协作，架构也是。 「善战者无赫赫之功，善医者无煌煌之名」，持续提升业务和架构能力，不要满足于当个救火队员。 「沟通创业价值，分享带来快乐」，坚持留言的第 12 篇。
2020-12-13 - spark 👍（12） 💬（1）
为了写心得体会，我读了专栏内容2遍和阅读了所有留言的内容，大家的留言内容让我受益匪浅。 追求架构的“道”，是需要直面的问题。抽象能力让我们抓住核心稳定的对象，自顶向下分解(专业分工)。同理心让我们理解用户的需求，组合我们的分解(协作精神)，分工是为了规模化和高效协作。 不仅仅是架构设计，团队整体形成架构共识也很重要，架构不仅仅在架构师的脑里创造，也需要在团队每个人的脑里达成共识。
2020-12-05 - 陈从宾 👍（9） 💬（2）
架构即人性： 1、组织架构解决的是人和人之间、组织和组织之间的分工和协作。“人”是一个最复杂和最不确定的元素，为了解决人自身的问题（惰性、会犯错....）、人和人之间的问题（主要是信任问题），人用机器来解决“人”相对确定的部分，然后不断的拓展可确定的部分。所以才有了各种机器，然后产生了很多系统。 2、软件架构解决的是系统或者组件之间的分工和协作。而系统或组件的源头是解决人的问题（提升人的效率、降低出错率）。其本质还是解决人和人之间的分工和协作问题。不管是分布式架构、微服务、单体架构，其实都是对现实中人和人之间协作方式中最佳实践的“机器实现”而已。所以做架构师一定要 有老师说的“洞察人性”的素质。 3、架构之间没有优劣，就像人和人之间没有绝对的对错，场景不同，所处的环境不同，知识背景不同，不要妄言对错。相对成熟一点的标椎可能就像老师传达的那样：帮助业务成长，促进组织成功。
2020-12-18 - E 👍（8） 💬（1）
乔老师这么多节课程其实一直在给我们布道“Trade-Off”的理念，要懂得前进，也要懂得刹车，不能陷入任何一种偏执的境地，随时提醒自己做这件事情的最初目的，不然容易走火入魔。
2020-12-04 - Weehua 👍（4） 💬（1）
从技术方面的架构师设计，我联想到了最近公司的一些组织架构调整和工作职责边界的问题。专业分工，正所谓术业有专攻，确实要让专业的人做专业的事情。组织分工明确之后，协作也很重要。有些组织调整，专业分工明确了，但是协作缺失了，也不能发挥组织的协同效用，不能做到取长补短。系统设计中，工作中，总有那些无法明确划分职责边界的灰色地带，这个时候怎么提高协作能力，就是考验技术管理者的“架构设计”能力了。 我也联想到了康威定律，有前辈说在工作中反过来看康威定律，会有不同的感受。
2020-12-14 - leslie 👍（2） 💬（1）
问题拆解、专人专事、协同合作，这就是我对于老师今天课程的理解。
2021-03-07 - Monday 👍（2） 💬（1）
好的架构设计，就像优秀的组织协作一样，既能帮助 IT 系统做好各模块的专业分工，又能体现模块间的协作精神 让我想到了多线程里的，分工和同步。
2020-12-08 - Keith T.Maxwell 👍（2） 💬（2）
这节内容我重复听了3个多小时。
2020-12-04 - 黄智勇 👍（1） 💬（1）
我前公司的老板是这样设计的，把所有的功能全部用存储过程编写，所有的页面都控件等都在数据库登记，全都可以配置，配置某个用户的某个界面的某个文本框的长度，按钮是否可见等等，最终实现类似SAP那样，页面大多都是实施人员配置，带来的后果当然是界面逻辑非常复杂，而且很难定制化页面 你觉得这样的设计有前途不？ 我觉得没前途，所以我离开了这个10年的创业公司，去了一家上市公司做 高级前端工程师 了
2021-02-11 - 许凯 👍（1） 💬（1）
架构的本质就是通过“分”与“合”（划分层级、修改要素和连接关系），打造一个有序对变化友好的系统，使其具备功能与配置完整一致正交、高安全、可监控、高可用、高扩展、高性能、低能耗。
2021-02-08 - 天涯若海 👍（1） 💬（1）
一直以来也认为架构的核心能力是抽象能力和分而治之的能力。抽象便于分工，分而治之便于协作。相辅相成，缺一不可。
2020-12-07 - 叶绘落 👍（1） 💬（1）
阅读的时候总是容易发散文章中的内容，将其与已知的事物联系起来，所以看待事物总会有似曾相识触类旁通的感觉。 在乔老师文章中让我更加明确了这个的想法。 抽象，复用。 这两个词汇不管就是根源。将具体的事物抽象成概念，将这些概念在不同的地方复用。 所谓道行高深，大概就是在抽象和复用上有很高的造诣吧。 那么有没有抽象和复用这两种行为的方法论呢?
2020-12-04 - Bravery168 👍（0） 💬（1）
乔总提供了另一种对架构思考的视角，和领域驱动设计的思路有殊途同归的意思。
2021-03-18 - 微风拂面 👍（0） 💬（1）
对乔老师的这章内容，非常有感触，可惜没有老乔的文笔，只能做出来，写不出来！
2021-02-13