一、前言
在做企业服务类(ToB)的产品时，我们经常会遇到如下场景：
每个客户拿着他们的需求清单，来咨询我们的产品是否可满足他们的诉求。如图所示：
每个客户的需求有重叠的内容，也有不一样的内容，而这些需求，在某一领域均具有较强的通用性。
如何满足这些客户需求的同时又能使各个需求沉淀为标准功能，而不仅仅是为了交付项目？这成为ToB类产品经理思考最多的问题。
为支撑客户诉求，基本的做法是抽象各个需求，落地为标准功能，将各个功能拼装成一个产品。但是一段时间后大家就会发现功能越堆越多、产品越做越庞大，但是用户体验却越来越差，产品开发维护越来越困难。 如何既能满足客户诉求，又能解决产品存在的这些问题？模块化设计是一个方向。后面我们展开介绍下，数栈在模块化设计方面的一些经验供参考。
二、模块化设计介绍
（一）目的
- 从商务销售的角度说，产品模块可自由组合报价，贴合不同客户的需求，提高产品销售的成单率。
- 从产品研发的角度说，减少重复造轮子的现象，提高研发效率和产品扩展性。
（二）落地经验 模块化设计在数栈平台的落地实施，从大到小主要分为下面三种方式：
- 子产品化
- 公共模块
- 组件/插件化开发
1、子产品化 1）需求背景： 每个客户，甚至同一个客户在不同阶段，对数据中台的理解都不尽相同。
- 比如客户A是个中等规模企业，希望能有款产品帮助他建设离线数仓，满足基本的数据开发诉求，那数栈的离线开发模块就可以满足他们的诉求。
- 比如客户B是个大型的集团企业，希望能从数据开发、数据服务、数据治理等多个方面搭建起集团数据中台，那就得输出一整套数栈去满足该客户。
2）设计思路：
- 产品上——根据业务逻辑，各个模块独立解耦，定位升级为子产品，负责解决不同的业务场景诉求。
- 商务上——销售时可单独报价输出，也可组合报价输出。
3）落地成果： 数栈作为一款数据中台产品，其中包含了：离线开发、实时开发、算法开发、数据服务、数据资产、数据质量、智能标签等子产品，每个子产品可解决不同的业务场景诉求，并支持独立、组合部署。
2、公共模块 1）需求背景： 数栈的各个模块独立化成子产品后，虽然可以解决不同的业务场景诉求，但是在数据中台这个框架内，仍然会存在一些相同的基础功能诉求，比如用户体系、数据源管理、任务运维等。如果每个子产品内部独立实现，会存在两个问题：
- 增加了用户的使用成本。比如相同的用户、相同的数据源需要在各个子产品内多次维护，而且还容易造成理解歧义。
- 增加了产品的研发成本。相同的功能需要重复实现，重复造轮子，浪费研发资源和运维成本。
2）设计思路：
- 剥离各个子产品中的通用功能作为公共模块，统一进行维护管理，然后为各个子产品提供服务。
- 公共模块的设计需要充分调研各个子产品的诉求。对于通用诉求，抽象出标准功能；对于拓展诉求，提供配置化功能；对于个性诉求，由子产品自行实现。
3）落地成果：
3、组件/插件化开发 1）需求背景： 如果说前两部分的模块化设计是对产品经理能力的考验，那这部分内容更多是对开发人员的要求。
下面介绍我们在日常工作中遇到过三个问题场景： a、产品设计时，需要新增一个输入框，要求是：属于必填项、内容格式限制中英文、长度限制255字符。
需求很简单，但是每次评审时，产品经理都得给研发说明如果为空时怎么提示、内容不符合格式要求时怎么提示、长度超过限制时怎么处理，沟通成本极大，而这仅仅是整个原型设计中1%都不到的内容。
b、产品设计时，需要复用另一个模块中的表单，表单中维护的各个表单项、表单项关联逻辑均相同。 功能完全一致，但是研发调研后发现，原有的表单处理逻辑和业务处理逻辑强耦合，导致表单代码无法复用，需要重新独立开发。
c、在产品迭代过程中发现存在一类需求，更新相对频繁，需求逻辑具有一定共性，而且更新不会涉及已有功能的改动。 这类需求对于开发，和公共模块之于产品类似，可以抽象为一种公共技术能力对外提供服务。比如我司经常会遇到的需求有：新增支持一种数据源、引擎新增一种任务类型等。
2）解决方案：
- 前端沉淀标准组件库。对于一些常用的设计，通过组件复用来减少开发和产品的工作量；目前我们已沉淀30 前端组件，并在持续迭代中。
- 代码的低耦合设计。这部分要求比较虚，而且没有非常明确的边界，依赖开发经验和对业务的理解，需要持续成长。
- 插件化设计。区分应用层代码和底层代码，底层代码进行插件化封装，可为上层不同的应用提供支持，在支持快速迭代的同时又不会影响已有功能，这样应用层开发可以投入更多地精力去支持业务。目前已落地：数据源插件、数据同步插件、Engine插件、血缘解析插件。
三、总结思考
模块化设计是一种解决方案，并不是最终目的，因此，在产品设计时不能为了模块化而模块化。尤其是产品初期，此时产品功能并不丰富，而且为了快速迭代抢占市场，并不适合投入较多的精力去做这个事情。但是一旦产品进入稳定发展期，产品经理和研发同学都应该开始思考模块化设计在日常工作中的应用了。
模块化设计并不是产品换个名称、独立做个页面就是模块化了，业务层面如何划分、模块之间如何配合、插件剥离的边界在哪，代码逻辑怎么解耦等等，这些都是需要思考的地方。
