把活儿省下来 · 集 10：系统长什么样，也是门学问

把活儿省下来 · 第二部第 1 篇（零代码）

面试一位程序员，问："介绍一下你项目的架构？"他张嘴就来："我们用微服务，中间是消息队列，缓存用的 Redis，数据库 MySQL。"听着很专业。你追问一句："微服务和 Redis，是一回事吗？哪个是你系统的骨架，哪个只是插上去的零件？"——十个人里九个卡壳。

面试一位管理者，问："介绍一下你们公司的结构？"他张嘴就来："我们事业部制，下设六个中心，后端共享服务。"同样很专业。你追问："事业部制和你们用的那套办公软件，是一回事吗？"——同样卡壳。

两人报的都是菜名，不是骨架。

而这一集要说的头一件事就是：不管软件还是公司，"长成什么样"这个问题，都有人研究了几十年，还把答案做成了货架。骨架怎么切，是有标答的。

---

一、软件那边：架构模式，切分系统的标答库

先说清楚"架构模式"是什么：在系统的最高层，怎么切分、怎么摆布、各部分怎么通信的一套现成方案。

它是写第一行代码之前就要定的事。先有骨架，再长肉——顺序不能反。

它也不管你用什么材料。分层可以用任何语言写，数据库可以随便换。它只管"长成什么样"，不管"用什么造"。

怎么跟之前讲过的设计模式区分？给你一个一辈子忘不了的类比：盖小区 vs 装修房子。 盖小区先做规划——哪儿盖住宅、哪儿留商业、路网水电怎么铺，这是城市规划，对应架构模式；某一户里沙发怎么摆、窗帘选什么色，这是室内装修，对应设计模式。两码事，尺度差着数量级。

具体差在哪？三条就分清了：

1. 尺度不同。 设计模式管几个零件怎么配合；架构模式管几大块怎么摆。
2. 频率不同。 设计模式天天用、随时调；架构模式一次定终身——改形态不是改代码，是搬家。这句话后面会反复回响。
3. 关注点不同。 设计模式关心"块内怎么配合"；架构模式关心"职责怎么切、依赖往哪指、数据往哪流"。

那这个标答库里都有什么货？几十年下来，软件系统的宏观难题翻来覆去就那么几种，沉淀出的标答也就那么几个：分层（竖着切，上层用下层）、管道-过滤器（横着流，数据一道道加工）、中介者（居中传话，大家互不认识）、微内核（核心只留最小，其他全做成插件）。先混个脸熟，集 11 起挨个拆。每个标答都自带一批前人标好的坑——你复用的不只是一个形状，还有形状背后的避坑经验和一套行话。

---

二、管理那边：组织结构图，就是公司的架构图

再看公司。一家公司要回答的问题，跟软件一模一样：切成几大块？谁管什么？信息怎么流？谁对谁说话？

管理界同样攒出了一批标答：职能制——按专业切，财务、人力、销售各一个部门；事业部制——按产品或市场切，每个事业部五脏俱全、独立作战；矩阵制——既按职能又按项目，双向汇报。这三个名字，就是组织界的"分层、管道、微内核"。

而且软件那边讲过的规律，管理这边一条不少：

管理也有骨架和零件之分。 事业部制是骨架；用哪套办公软件、哪个考勤工具，是零件。开头那两位面试官卡壳，就是报错了层次——谈结构的时候，该说的是切分和流向，不是工具品牌。

管理结构也一次定终身。 从职能制改成事业部制是什么动静？账要拆成几本，部门协作变成内部结算，人要跟着重新分，考核要重新定——这就是搬家。多少公司的组织变革一改改三年、改伤元气，就是把搬家当成了重新摆家具。

管理结构也自带共同语言。 你跟合作方说一句"我们是事业部制"，对方立刻明白你的权责怎么切、报表怎么走，省掉半小时解释。用上了标答，顺带也用上了描述标答的话。

最后送管理者一个软件那边换来的概念：骨架一定，零件就有了槽位。 软件里，先把分层定下来，数据库、消息队列这些现成零件才知道往哪儿插；公司里，先把结构定下来，招什么岗位、买什么系统、外包什么活，才知道往哪儿放。没有骨架，买再好的零件也只是一堆零件。

---

三、两张图叠在一起：先定骨架，再长肉

软件：架构模式	管理：组织结构	两边其实是同一件事
切几大块、块间怎么说话	设几个部门、权责怎么切	顶层形态问题，先于一切细节
分层 / 管道 / 中介者 / 微内核	职能制 / 事业部制 / 矩阵制	标答库：反复验证过的形状
设计模式 vs 架构模式（装修 vs 规划）	管理工具 vs 组织结构（摆件 vs 架构图）	分清骨架与零件，别报错菜名
改形态 = 搬家	组织变革 = 三年动骨	结构是最贵的复用品
骨架一定，零件有槽位	结构一定，岗位与系统有槽位	先定形状，再买家具

结论可以这样拍：架构模式和组织结构，是同一件事的两副面孔——这次复用的不是零件、不是经验，而是形状本身。 搭新系统、建新公司时，你面对的不是"从零发明一种摆法"，而是"从标答库里挑一个合身的"。挑哪个、怎么挑，接下来两集讲。

---

四、这一集的账：让系统形状有标答，省了什么

省下来的：一套切分系统的标答库，附带每种形态的避坑清单。省的东西从"单件"升到了"形状"——这是这一部跟上一部最大的区别。

怎么个省法：认清场景，挑合身的形态，套上骨架。不是发明形状，是选择形状。

省的代价：结构是改起来最贵的东西。骨架错了，零件全要重插。所以架构决策总是慢、慎、重——这不是效率低，是应有的敬畏。

下一集说：标答库里用得最多、几乎所有大系统和大组织都长成的那副骨架，是什么？是"层"。你会发现，它跟组织里的等级链，是同一张图。

---

五、今天带走一句话

系统的形状本身也是复用品：软件的架构模式和管理的组织结构，都是从几十年翻车经验里沉淀出来的标答库。先定骨架再长肉；改形态是搬家，不是摆家具。

送你一条可执行的自查：下次听人介绍系统或公司，先问自己——他报的是骨架，还是零件？ 报一堆工具名的是零件清单；能说清切成几块、谁跟谁说话、信息怎么流的，才是真懂结构的人。

下一集：《为什么都长成金字塔》——为什么全世界的软件和全世界的组织，不约而同长成了金字塔。