b端教育产品设计时,如何降低模块之间的耦合,做低耦合设计??

作为一名面向教育机构b端产品经理，往往需要设计的是整个教育行业的方方面面的流程，当然，通常情况下是按照模块的不同进行设计，比如学生相关模块、教师相关模块、考试相关模块等。这些模块、功能、流程或复杂或简单。简单的流程就不必说了，当设计复杂功能模块时，模块之间很强的逻辑联系，较高的数据依赖性，在流程梳理和整个设计过程中，是令人十分头疼的事儿，那么怎样在一开始通过梳理和分析，达到简单优雅的设计，这样的问题就摆在我我们面前。

复杂的功能模块除了本身的流程复杂外，最重要的是它是建立在别的较完善的模块流程的基础上，同样模块流程本身的输出又是另外的一个模块完善的前提，这样交织的模块关系，使整个系统错综复杂，具有较强的耦合度，在做功能扩展的时候，牵一发而动全身。

降低模块之间的耦合度是十分重要的一件事儿，其优势如下：

1.模块之间的耦合程度越低，相互影响就越小，发生异常后产生连锁反应的概率就越低；
2.在修改一个模块时，低耦合的系统可以把修改范围尽量控制在最小的范围内；
3.对一个模块进行维护时，其他模块的内部程序的正常运行不会受到较大的影响；                                                   那么，如何做到降低系统模块之间的耦合度？笔者认为可以从以下入手: 

在软件工程中，降低耦合度，又称“解耦”，模块间有依赖关系必然存在耦合，理论上绝对的零耦合是做不到的，但是可以通过一定的方法将耦合度降至最低。B端系统在设计时解耦的方法要从逻辑，研发两方面考虑。作为产品经理将产品线的发展规律，管理差异化，系统平台支撑方面进行逻辑梳理。当然技术方面也要进行模块化微服务。做到客户，合同，付款，服务，服务评价五个维度的数据闭环。模块间数据传输，模块内部逻辑判断。开发人员应该尽量使用数据耦合，较少使用控制耦合，限制公共耦合的使用范围，同时坚决避免使用内容耦合。

言归正传,产品经理如何在一开始设计的时候降低各应用模块之间的耦合度，这是本文讨论的重点：

一开始就做到最优解耦不太容易，这是一个从混沌走向清晰的渐进明细过程，我个人认为可以从以下几方面来入手：

1.明晰并理解需求，了解现有的系统：

（1）业务流程图：B端以业务流为主，业务流程图是首要需要明确的，而且需要足够概括，抽象，这样业务流程可以按不同角色来进行划分，每个角色在每个环节在什么情况下都需要干什么、有什么权限、涉及到什么模块和数据等，由此也可把角色权限进行定义了；

（2）流程状态梳理：就是不同的业务流，有哪几种状态，每种状态之间切换的条件是什么，到底有多少条通路，需要模拟各种情况的数据走一遍；

（3）系统架构图：整体的系统架构是由不同的流程不同状态构成的公共合集，在设计系统架构图时，需要明确涉及到的前台业务、底层系统、各个系统模块，明确业务范围，若有改动涉及到其他系统，需要梳理并抽取出共性；

通过这几个步骤，由业务流转化为了抽象的系统架构图，当然这是产品自己梳理的1.0版，还需要对整个系统影响的各相关方进行访谈；

2.对上下游系统相关方进行访谈，根据访谈结果综合分析后更新相关流程图、架构图：

（1）现有系统的研发人员：系统能实现什么不能实现什么，肯定看了代码就知道了，梳理相关逻辑的时候可以分专题与研发人员进行讨论，一定要控制好不要跑题；

（2）熟悉相关业务的产品或项目经理：熟悉历史经验教训及组织过程资产往往能够降低后续的项目风险，有哪些是设计如此、哪些是遗留问题，相关的产品同事多少会知道一些；

（3）运营、最终用户及测试人员：运营人员与最终用户是使用系统最多的相关方，运营与测试人员往往能提出很多绝妙的优化建议，有利于产品同事进行梳理；

3.配合营销指标及技术指标进行优化，虽然这是后期的事儿：

很多时候系统的业务量或用户量达到一定程度时会遇到瓶颈，市场同事在销售时也肯定会有相关的数据指标，产品的设计、模块的解耦往往也可以与这些需求一并考虑；

（1）技术优化如：业务延迟的忍耐程度、流程的长度、数据的归档周期等；

（2）营销指标如：线索和商机的获取周期、用户的使用体验等；

在具体操作的时候，我们可以采用以下思路：

1、梳理原子服务：

     梳理承载业务的系统所需要的模块，然后将这些模块拆分为一个个功能点，将相似的功能点合并为一个独立的服务，提供单独的一项能力，合并服务要保证每个服务都可以单独对外提供服务且每个服务提供的能力不重合，这种称之为原子服务：

这个步骤的完成的好坏取决于：

1）你对业务对理解能力，如果是从0-1可以参考其他教育行业友商竞品，如果不是可以参考现有系统；

  2）你对业务所处行业发展的思考，这个很大程度决定你服务的拓展性和合理性，这个可以结合行业发展史和你自己的知识认知，比较抽象。

3）边界一定要清晰，要明晰所做功能的边界和现实中技术的局限性，既要天马行空、又要明确系统边界；

2、找出这些服务里面的共用项，把他做成最底层的配置规则，然后让他服务来调用。举个例子，设施设备管理及相关数据采集，经常涉及多硬件、多变成语言，那么每个模块的框架语言包就是一个共用项。这样做的目的是保证各维度数据的一致性；

3、在进行完前面两个步骤以后，会发现，有时候一个业务闭环其实需要多个服务一起提供服务，这个时候，需要再加一层服务聚合，保证原子服务的独立性；

总之，一般应该采用：梳理出独立原子服务（保证独立不耦合）-找出公共底层配置项（保证维度数据统一）-聚合服务支持业务（保证原子服务解耦）这样的流程；

充分的降低各个模块的耦合性，是复杂的教育系统必须解决的问题，系统的解耦要从逻辑，研发两方面结构。将产品线的发展规律，管理差异化，系统平台支撑方面进行逻辑梳理。技术方面要进行模块化微服务。

这样对后期产品功能的扩展、系统的演进都会有很大的帮助。