最近在做项目的复盘，大脑中一直挥之不去的是几个字，「高内聚，低耦合」，下面会用3W1H的产品分析方法，来解读【高内聚，低耦合】，此文是针对产品设计相关知识的总结归纳，希望能给你带来相关的帮助。

什么是高内聚，低耦合？

高内聚：首先我们来看看内聚的含义：软件含义上的内聚其实是从化学中的分子的内聚演变过来的，化学中的分子间的作用力,作用力强则表现为内聚程度高。在软件中内聚程度的高低，标识着软件设计的好坏。

低耦合：低耦合是用来度量模块与模块直接的依赖关系。耦合当然也可以这样简单的理解，我想懂电脑的应该都知道，CPU与主板之间的关系，CPU如果是特殊的CPU必须使用特殊的主板来支持，那么如果说这个CPU不唯一依赖唯一主板，那么就认为这个CPU与主板的关系是低耦合的关系。

      从内外关系讲，高内聚讲究的是内部主体的聚合，低耦合讲究是主体与外部主题的关联性，我们可以把高内聚和低耦合的此可以拆解，主体可以当作我们现实中的实际物品如iphone手机来讲，对于业务需求主题（手机）来讲他是高内聚的产物，他可以打电话，发信息，玩游戏，闹钟，录音机，如果是低内聚就会造成我们不仅仅需要大哥大，还需要游戏机，还需要一台闹钟，所以高内聚是在人和物上建立需求关系的诉求；耦合，我们也可以以手机为例，一台iphone 手机是由1000多个零部件组成，在全球有数白家供应商，手机有屏幕，摄像头，音响等等组成，如果把手机屏幕当成一个主体，手机屏幕和摄像头不是必备关系，即使手机屏幕坏了，我也可以用其他的屏幕进行替换，这种低耦合关系，屏幕可以复用维护成本低，如果是高耦合，如果手机和摄像头有一方坏则统统需要更换。

     同理软件系统是一个超大型项目，由千万行代码组成，怎么做到用户好用，而不至于牵一发而动全身，往往是评估一个软件的好坏。

为什么要做高内聚，低耦合？

        在what层其实已经讲了高内聚，低耦合的好处，下面会已具体的实例来讲解。

应用架构案例

下面调研到学员从线索到具体的课耗流程涉及的业务主流程，大体上所有的教育行业都会涉及到这些职能岗位老师

进一步调研到销售职能域的相关职能老师的需求

根据IRP分析方法进行总结而来

线索数据无非会经历四个阶段：录入，分配，跟进反馈，转化，下面做了简单的业务过程分析；

销售职能域分析

   以上是对销售域的分析，这里销售域的应用架构，对于销售域职能老师来讲是否有必要拆分为 多个应用：如线索分配应用，市场管理应用，CRM应用，分析所得销售职能域的最终结果都是对【线索数据】的转化（管理），所以我们可以高度聚合在一起，如果是低聚合则会导致应用层交互不友好，若出现一人身兼多个职能的情况，则需要三个实体应用；如果低聚合在数据层导致数据主体分散，导致跨表；

应用内聚和数据内聚

    在耦合层我们也可以分析，销售数据和教务数据及财务数据能否实现低耦合，未来系统扩展能否直接用到财务模块和教务模块；

由此可见，应用层的高内聚，低耦合可以使应用交互友好，应用可以复用，每个模块应用使用自己的数据，而不至于该应用数据或功能的改变，导致其他应用无法使用的情况。

权限架构案例

     如某业务线的产品蓝图如下，业务线有很多产品，每个产品都有数据权限的设置；数据权限的设置是否是整个业务产品平台的基础数据还是每个单个应用的数据，若是基础权限数据，则会导致账户授权会影响所有的应用，所以考虑高内聚低耦合的情况，我们更多的将它设置为单个应用的权限数据

产品蓝图，小方框内为独立的产品

每个帐号设置数据权限都有本人数据和全部数据权限架构案例

功能才能案例

 在教务环节，原有的课表学员有：在班学员（正常进入班级），请假补课（请假补课进来），临时补课（临时调课进来），现业务需求需增加试听学员，并且试听学员的考勤和其他学员的考勤完全不同

新增（试听学员）

下面会展示两种方案来解决试听学员的考勤问题：

方案一：原基础上进行重构，试听的新增会导致现有的考勤状态优化，试听代码耦合与先有的考勤代码耦合太高，重构成本和维护成本及培训成本都比较高昂，现有的设计方案会与之前的方案形成耦合

方案一

方案二：只增加出勤-不计费功能满足试听需求场景，不影响先有逻辑，低耦合处理，只是做叠加行为，不管在使用成本，维护成本，回撤成本都比较低。

方法二

在需求易用性和代码维护性的情况下，个人更会倾向方案二；

以上的举例对于高内聚，低耦合会有以下总结：

内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系；

耦合更多的是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。

高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准

在系统层面应该什么时候（where）如何(HOW)更好去实现高内聚低耦合？

软件工程的生命周期

业务建模是设计软件的基础，大量的时间调研现有业务的主流程，职能域，业务过程，业务活动分析出来（这里可以推荐IRP分析方法和DDD分析方法），能基于业务需求，我们才能更好地产品设计，实现软件的高内聚和低耦合

应用划分及架构层

应用架构会有三个维度，如下：

1.应用划分：高内聚低耦合设计;

2.权限架构：高内聚低耦合设计;

3.账号架构（也可以叫账号体系，怎么做到统一账号）：怎么能做到单一的账号能访问不同类型的应用，这里的应用可以是集成的第三方应用，也可能是自建应用

数据建模层

这块会涉及到

1.主流程数据建模：在满足业务的情况下怎么样减少数据耦合是需要大量的时间去做头脑风暴

2.数据建模尽可能满足的主业务需求，如财务环节不不仅考虑学员课程的购课和退费流程，还要考虑换课的流程,因为换课也是比较常用流程

总结：数据建模会在功能层直接影响到数据的流转和软件的扩展性，数据建模如果存在问题会导致后期需求与现有的数据发生对冲关系，直接会影响到软件的扩展性和易用性

产品设计层

产品设计层，这边会更多地以交互层来说明，战略层，框架层，范围层，结构层，UI视觉层，我们拿结构层举例

结构上我们要将功能相同的页面进行聚合，这里就不过多累赘

总结

     以上就是本人对如何做权限设计的总结分析，仅供大家参考，希望在工作中能够帮助到大家，也希望大家一起多提意见，指出不足，感谢阅读！