指南编辑：在谈到系统体系结构时，建筑师们总是提到“高内聚”和“低结合”，这是系统设计中非常重要的概念，也是产品经理为了更好地开展业务而必须学习和思考的必要技术要点。作者以生动的故事为例，同时看到了他对高低耦合的理解。

在与建筑师讨论系统设计时，到处都能听到“高内聚”和“低情侣”的声音，就像是技术和产品之间的墙、初级和高级之间的沟渠一样。但是如果你理解它们的原理，就不会那么神奇了。这两个词是R & amp要知道不是d专用的。作为产品经理，我们对这两个词的理解可能比建筑师更广，扯概念可能比他们更酷。

这篇文章的文笔以一个故事开始，以另一个故事结束，谈谈你我眼中的婆家聚集和低情侣关系，往下看！

在谈到系统架构时，建筑师们总喜欢把“院内聚会”和“低情侣”挂在嘴边，拉着，把不认识的人蒙在鼓里。好像是技术和产品之间的墙，初级和高级之间的沟。那么，究竟什么是高内聚合和低耦合，对系统设计有什么影响？事实上，理解了它们的原理后也是这样。

今天木笔用美丽的北漂故事讲述了我对这两个词的理解，相信你读完这篇文章后，也能和这些建筑师互相拉扯。而且，产品经理眼中的高内聚和低耦合不能局限于系统设计本身，要思考更为根源的工作方向，从业务层面进行内聚和耦合。

和建筑师互相吸引时，我要酷拉。气势不能输。即使脸部浮肿，也要保持迷人的微笑和骄傲的姿态。不要给我们的产品经理丢脸。是你。

一、从北京爱情故事说起

故事是这样开始的。

老金、老张、老李三人是大学同学。大学毕业后约定一起去北京。由于初入社会工资比较低，为了节省房租，三个人一起租房，一个房间放了两张下铺，延续了大学宿舍的生活方式。每天下班后一起喝酒、吹牛、玩游戏，周末时间充裕

这样快江湖的日子持续了三年，三只单身狗分别交了女朋友，偶尔来了一个女朋友，另外两个为了避风头要出去。不舒服。所以三个人加起来租了一间大卧室，每人一间，这样就解决了女朋友来小聚会的问题，三个人也可以继续一起逍遥。随着住宿条件的改善，小情侣们的感情高涨，为了克服思念的痛苦，最大限度地利用国家资源，小情侣们设法克服各种障碍，共同同居，原来三个人家里住着6个人。住宿，住宿，住宿，住宿，住宿，住宿，住宿，住宿。

3人成为3户6口人后，原来快活的日子开始慢慢发生微妙的变化。因为房间隔音效果不好，愤怒的老陈和女朋友经常吵架，闹到半夜，严重影响了隔壁李和张。时间长了，两个儿媳故意见面。而且，三家也因为厨房和卫生间的使用经常发生冲突，媳妇之间的事情不再像以前的三个老爷们那样简单粗暴地处理，一旦处理不好，后果大家都知道。

6个月后，为了避免女朋友之间的矛盾，不能再交往了，张、李、老陈最终决定不再续租，三个人分别带女朋友租单间，周末有空的时候聚在一起。这样，陈虽然还经常和女朋友吵架，但依然睡得晚，但是三家合租时遇到的所有问题都解决了，没有冲突，三个女朋友见面后反而比以前合租时更加亲切。

故事结束了。如果你们也有过几个相似的室友和经验，那就很幸运了。因为正好同学少年们合租的日子是短命的，微妙的，短暂的。因为一起为了梦想而贫穷的日子最终会成为人生旅程中最珍贵的回忆，它最终在任何时候都不会回来一次。

但是这篇文章的重点不是缅怀青春，而是想从故事中提取我们需要的主要因素——高内聚集和低耦合。从资源分配的角度分析为什么前三个人合租的时候关系很好，如果三个合租换了，就会产生矛盾，后来各自分开住，关系又好了？先考虑三秒钟。

第二，什么是高内部聚集和低耦合？

暂且抛开故事，我们首先要理解什么是内聚和结合。

内部集合是指某事物内部各要素之间的紧密联系程度。同样的因素越集中，聚集越高，相反的情况就越低。例如，人身体里的五脏六腑从出生开始就互相合作。换成别人的器官会出现排斥现象。这就是古内聚。

结合是指不同事物之间的依赖性。彼此的依赖性越强，结合性越高，反之则越低。以人体为例，心脏是供血，肺是呼吸，肝脏是代谢，彼此分工明确，各司其职明确，不管哪个部位疼，只要针对性治疗就行，不影响其他部位，这就是低耦合。

理解概念后，再回来分析故事的结局。为什么前三个人合租的时候关系很好，三家合租的话会产生矛盾，后来各自分开生活，关系又变好了？

答案公布：前三个人合租时省钱最重要，感情少，事情简单，所以不会有太大矛盾。到了第三家就变成了三个不同的家庭，每个家庭的计划和诉求不同，省钱不再是第一个诉求。在同一屋檐下，老陈和女朋友的家务事只能影响老张和老李两家。另外，大家平时共享厨房、卫生间等公共资源，只要一个家庭使用，其他两个

最后随着三家分开以后，自己过自己的生活，再也不会影响到其它两家，矛盾自然就没有了，随着偶尔的联络聚会，还会增进彼此的感情。

老陈、老张和老王的合租

这就是高内聚和低耦合的原理。最初三人合租时，人少、有感情基础，省钱第一，不存在内聚和耦合问题；三家6人合租时，彼此之间依赖太多，任何一家的举动都会影响到其它两家，耦合性太高，所以容易出问题；分开以后，每家独自负责自己的生活，不再依赖别人，内聚性变高了，同时只有周末才会相互联络，耦合性降低了，所以关系更亲近了。

看看，是不是和我们的系统设计一样一样的？当系统很小时，为节约资源，大家在一起共用一套资源，这样效率最高，而随着系统和团队的复杂度逐渐提升，彼此之间的依赖越来越高，就会经常出现资源问题和发展瓶颈，到最后，为了解决耦合性高的问题，只能对系统和团队进行拆分，各司其职，最终演变成了标准的高内聚和低耦合模型。

三、如何实现高内聚和低耦合

从定义上，我们应该清楚了高内聚和低耦合其实说的是两件事，一件事对内（高内聚），一件事对外（低耦合）。站在产品的视角，高内聚和低耦合不应该只局限于系统设计层面，那样就显得比较狭隘了，正确的解读应该立为业务和系统两个层面。

高内聚与低耦合示例

1. 业务层面

无论是业务部门的责任分工、流程的规划和设计，还是作业现场的管理，都需要遵循高内聚和低耦合，我们应该尽量将相同的职能、流程和运营工作尽量集中式管理，而不同职能、流程和运营之间责任和边界清晰，沟通协作顺畅且不相互影响，具体体现为：

（1）各部门和岗位分工明确，各司其职。例如采购、仓储和配送，虽然交集很多，但在定人定岗时，就应该是不同的岗位角色，即便有的公司很小，可以一人身兼数职，但也要清楚，只是一个人做了多个岗位的事，而不是多个职能融合成了一个岗位。

（2）各项流程清晰，职责单一。在设计业务流程时，应该考虑单一职能原则，每套流程解决一个核心业务场景，虽然很多时候人和功能可以复用，但在流程和规则层面还是要分开设计，不要混在一起。例如销售出库和退供应商出库，虽然都是出库，系统功能和操作人都可以复用，但出库的对象不同，应该视为两种业务流程。

（3）现场管理规章明确，流向清晰。在仓储中心、物流中心的现场管理时，需要按照不同岗位、不同商品和不同业务形态规划库区、动线流向，制订规章制度，例如收发货区域管理、整件和散件区域管理、大件区和中小件区域管理等，让每个流程对应不同的规则，每个区域负责不同的存储形态，每个岗位操作不同的业务单据，彼此之间能无缝衔接却又不相互干扰。

2. 系统层面

在做系统设计时，需要保证相同的系统和功能模块尽量内聚，系统和功能模块之间尽量解耦，体现为：

• 系统和模块职能单一，边界清晰。在规划系统时，应该做到每个系统，以及每个系统下的每个功能模块都有很清晰的职责，核心职责只有一个，并且和其它模块之间有比较清晰的边界，避免模棱两可。例如库存模块负责处理所有库存相关事宜，入库模块负责处理入库业务流程，二者的边界在入库上架时对库存的处理，由入库模块触发，库存模块做执行。
• 数据和逻辑统一，唯一主责方。每个数据和逻辑的操作应该只有一个主责方，当其它模块需要操作此数据时，应该由此模块授权并通过接口服务的方式互通，如此可以最大化的保证数据和功能的完整和安全。例如入库和出库都需要操作库存，但库存的逻辑统一由库存模块来处理，出入库操作库存需要通过库存模块提供的接口来交互，千万不要把库存的处理直接交给入库和出库模块来各自处理。
• 与尽量少的系统交互，降低系统之间的复杂性。参考软件设计原则里的迪米特法则：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers），尽量避免多个系统之间相互交互，形成了笛卡尔积和网状结构。比如上方有3个ERP，都需要要与下方的3个WMS系统做交互，这个时候就应该考虑通过一个中间的系统来对上承接3个ERP，对下对接3个WMS系统，不要让每个ERP分别与每个WMS形成笛卡尔积。

当然，高内聚和低耦合的设计虽然看起来更合理，但在实现时还是要因时制宜，因为高内聚和低耦合的实现一定会带来人力成本和系统实现成本的增加，就像北漂故事中一样，老陈老张和老李三家分开以后，确实实现了高内聚和低耦合，但每个人都需要自己租单间，还需要置配生活用品和厨房用具，总成本一定比合租时要高，比起最初三人合租一间房时就更高得多了。

在设计流程和系统时，我们应该根据实际情况来定夺，没必要照本宣科过度设计，在此，木笔提供几个思考建议：

• 系统设计来源于业务，做系统的内聚和耦合之前，先从业务层面进行梳理，让业务先做好高内聚和低耦合，很多时候问题不是出在系统上，而是业务侧没有做好内聚和解耦。
• 当业务发展初期，流程和系统相对简单且未来尚不清晰时，需要快速试错，可以不用太考虑内聚和耦合（适当兼顾就行），先以成本最低的方式支持业务，等业务慢慢清晰以后再继续调整也不迟，千万不要过度设计，用10万单的规模架构太承接1000单的业务，实打实的浪费。
• 如果业务相对稳定，长期不变，适当耦合会更合理，比如商品的基本属性、订单的关键信息、地址库信息等，没必要为了低耦合，每次都做接口交互，这样比较浪费性能。
• 当业务体量和团队规模都很小时，适合合租模式，一套系统中考虑按模块做高内聚和低耦合最合理；而当业务规模较大时，适合分开自住模式，分成多套系统，各系统内部高内聚，系统间低耦合更合理。

四、小Q的故事分享

最后，我们分享一个小Q的故事来加强对高内聚和低耦合的理解。

小Q最近有点烦，事情经过是这样的：

上个月自己刚入职了Z公司负责仓储系统的产品工作，刚入职就遇到前任产品经理离职，两人在交接的过程中才知道这套WMS系统是前不久才开发上线的，但因为系统问题较多，导致系统库存记录的严重不准，才1个月就产生了1000多万的账实差异，而且差异越来越大，已经严重影响了公司的销售，每天被销售部门、仓储部门和财务部门多方逼着解决，前任实在顶不住压力了，所以才提了离职，后来公司才招了小Q入职……原来如此。如果要评出职场上最坑的事，这种入职即背锅一定能排进前三。

小Q刚开始还没意识到问题的严重性，直到被仓储业务方在邮件里将盘点差异直接抄送CEO，并点名要求技术部门为库存差异负责并责令修复系统问题，限期1个月。为了不惹火上身，小Q当即提出离职，被领导好说歹说挽留下来，并为其增加了绩效奖金，因为目前最专业的人只有小Q了，只能死马当作活马医。重赏之下，两人商定以1个月为限，领导答应给小Q协调足够的资源来解决此问题。

小Q拉上研发经理和测试经理成立了专项组，先从业务的差异数据开始着手，从差异最大的业务开始排查，不多久便根据自己的经验发现了问题的根本：新的WMS系统研发团队都没有库存处理相关经验，在做库存处理设计时，都是在各个业务模块中自行处理，各自模块负责自己模块的库存加减，直接操作库存表，这样看起来各业务之间互不干预，似乎很解耦很合理。

但大家都忽略了一个现实：业务是并行的，在入库的时还可能在做出库、盘点等业务，虽然每个业务都是各自开展，但一旦针对某一个SKU同时操作多个业务时，库存的处理就会相互牵制，往往上一个业务还没处理完库存，下个业务又对库存操作了变更，这就产生了库存的操作错乱，所以产生了库存差异。看起来解耦的设计，实际上是各种业务和库存的处理高度耦合导致的问题。

Z公司的库存处理现状

这么严重的问题，测试时为什么没有发现呢？因为测试时样本太少，根本没有测到这种业务并发的情况。

找到问题根本以后，小Q稍微松了一口气，根据经验很快出具了一个库存解决方案：将库存的处理单独抽出来做成公共服务，整个系统只能基于此服务操作库存表，保证前一个业务加减完成后再执行下一个业务操作，并记录详细的库存变更流水日志。

对外则提供公共的库存的加减公共服务，这样各仓储业务环节只需要处理业务逻辑，在需要变更库存时再调用库存服务完成对库存的处理，不用再关注库存的底层逻辑了，如此才是真正的各业务内部高内聚（每个业务只关注处理自己的业务逻辑），业务和库存之间低耦合（通过唯一接口交互）。

小Q改造后的库存处理方案

方案出具以后，技术团队用1周时间完成了库存的重构，并按照差异大小排序，将各业务逐一往新的库存服务中迁移，虽然业务仍然在天天紧逼，但看着库存差异在一天天缩小，小Q知道自己的新方案凑效了，如此下去，不到1个月，库存问题就能得到彻底根治了…

案例也分享完了，以上就是我个人对高内聚和低耦合的一些见解了，最后想说的是，高内聚和低耦合的设计只是最终的实现形式，而它们更多的价值体现在我们梳理过程中的一种结构化思维方式，这是一种放诸四海都有用的方法。在做内聚时，我们要学会归纳、抽象，让相同的业务和功能尽量紧凑，在做耦合时，我们要学会将联系比较密切的流程、逻辑和功能拆分、剥离再重组和内聚，切忌藕断丝连。

我的文章分享完了，观点如上，够不够出去拽一下，就看你的了。

#专栏作者#

木笔，产品一俗生，深耕于供应链领域，微信公众号：供应链产品笔记

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议