B端产品怎样降低模块之间的耦合？

设计复杂功能模块时，模块之间的逻辑联系很强，数据依赖性也较高，怎样在一开始通过梳理和分析，达到简单优雅的设计呢？

B端产品怎样降低模块之间的耦合？
这是一个从混沌走向清晰的渐进明细过程，可以从以下几方面来入手：

1.了解当前业务系统，理解需求
在收集需求并明确范围后，要熟悉现有系统的实现方式，以及其与上下游系统的数据交互方式，在理解之后，需要根据自己的理解输出：

系统架构图：明确涉及到的前台业务、底层系统、各个系统模块，明确业务范围，若有改动涉及到其他系统，需要梳理并抽取出共性
状态机：就是不同的业务流，有哪几种状态，每种状态之间切换的条件是什么，到底有多少条通路，需要模拟各种情况的数据走一遍
业务流程图：架构明确了，状态清楚了，业务流程自然也就出来了，业务流程可以按不同角色来进行划分，每个角色在每个环节都需要干什么，由此也可把角色权限进行定义
2.对所影响系统的相关方进行访谈
B端产品往往会涉及到多部门多角色，不同的角色有自己的需求，这里的相关方包括：

现有系统的研发人员：系统能实现什么不能实现什么，肯定看了代码就知道了，梳理相关逻辑的时候可以分专题与研发人员进行讨论，一定要控制好不要跑题
熟悉相关业务的产品或项目经理：熟悉历史经验教训及组织过程资产往往能够降低后续的项目风险，有哪些是设计如此、哪些是遗留问题，相关的产品同事多少会知道一些
运营、最终用户及测试人员：运营人员与最终用户是使用系统最多的相关方，运营与测试人员往往能提出很多绝妙的优化建议，有利于产品同事进行梳理
3.配合营销指标及技术指标进行优化
很多时候系统的业务量或用户量达到一定程度时会遇到瓶颈，市场同事在销售时也肯定会有相关的数据指标，产品的设计、模块的解耦往往也可以与这些需求一并考虑

技术优化如：业务延迟的忍耐程度、流程的长度、数据的归档周期等
营销指标如：线索和商机的获取周期、用户的使用体验等
B端产品怎样降低模块之间的耦合？
想清楚并不简单。

一个分析框架思路
1、梳理承载业务的系统所需要的模块，然后将这些模块拆分为一个个功能点，将相似的功能点合并为一个独立的服务，提供单独的一项能力，合并服务要保证每个服务都可以单独对外提供服务且每个服务提供的能力不重合，这种称之为原子服务。（相互独立，完全穷尽）

这里面有3个比较重要的点决定梳理的质量：

1）对业务对理解能力，如果是从0-1可以参考竞品，如果不是可以参考现有系统。

2）对业务所处行业发展的思考，这很大程度决定了服务的拓展性和合理性，这个可以结合行业发展史和自己的知识认知，比较抽象。比如通讯：信件-有线电话-无线电话-手机-可穿戴设备-脑机植入-… 这个例子可能不太恰当，因为这里涉及太多硬件服务的变更，而软件最底层的服务很大程度是不变的，只会不断革新技术。

3）边界一定要清晰。

2、找出这些服务里面的共用项，把他做成最底层的配置规则，然后让其他服务来调用。举个例子，跨境电商经常涉及多语言，那么每个模块的框架语言包就是一个共用项。这样做的目的是保证各维度数据的一致性。

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

总结一下：梳理出独立原子服务（保证独立不耦合）-找出公共底层配置项（保证维度数据统一）-聚合服务支持业务（保证原子服务解耦）