数栈产品分享:干货解读数据中台产品「模块化」设计思路

1、前言

在作企业服务类(ToB)的产品时,咱们常常会遇到以下场景:html

每一个客户拿着他们的需求清单,来咨询咱们的产品是否可知足他们的诉求。如图所示:前端

每一个客户的需求有重叠的内容,也有不同的内容,而这些需求,在某一领域均具备较强的通用性。git

如何知足这些客户需求的同时又能使各个需求沉淀为标准功能,而不只仅是为了交付项目?这成为ToB类产品经理思考最多的问题。github

为支撑客户诉求,基本的作法是抽象各个需求,落地为标准功能,将各个功能拼装成一个产品。可是一段时间后你们就会发现功能越堆越多、产品越作越庞大,可是用户体验却愈来愈差,产品开发维护愈来愈困难。
如何既能知足客户诉求,又能解决产品存在的这些问题?模块化设计是一个方向。后面咱们展开介绍下,数栈在模块化设计方面的一些经验供参考。算法

2、模块化设计介绍

(一)目的框架

  • 从商务销售的角度说,产品模块可自由组合报价,贴合不一样客户的需求,提升产品销售的成单率。
  • 从产品研发的角度说,减小重复造轮子的现象,提升研发效率和产品扩展性。


(二)落地经验
模块化设计在数栈平台的落地实施,从大到小主要分为下面三种方式:运维

  • 子产品化
  • 公共模块
  • 组件/插件化开发

一、子产品化
1)需求背景:
每一个客户,甚至同一个客户在不一样阶段,对数据中台的理解都不尽相同。ide

  • 好比客户A是个中等规模企业,但愿能有款产品帮助他建设离线数仓,知足基本的数据开发诉求,那数栈的离线开发模块就能够知足他们的诉求。
  • 好比客户B是个大型的集团企业,但愿能从数据开发、数据服务、数据治理等多个方面搭建起集团数据中台,那就得输出一整套数栈去知足该客户。

2)设计思路:模块化

  • 产品上——根据业务逻辑,各个模块独立解耦,定位升级为子产品,负责解决不一样的业务场景诉求。
  • 商务上——销售时可单独报价输出,也可组合报价输出。

3)落地成果:
数栈做为一款数据中台产品,其中包含了:离线开发、实时开发、算法开发、数据服务、数据资产、数据质量、智能标签等子产品,每一个子产品可解决不一样的业务场景诉求,并支持独立、组合部署。工具

二、公共模块
1)需求背景:
数栈的各个模块独立化成子产品后,虽然能够解决不一样的业务场景诉求,可是在数据中台这个框架内,仍然会存在一些相同的基础功能诉求,好比用户体系、数据源管理、任务运维等。若是每一个子产品内部独立实现,会存在两个问题:

  • 增长了用户的使用成本。好比相同的用户、相同的数据源须要在各个子产品内屡次维护,并且还容易形成理解歧义。
  • 增长了产品的研发成本。相同的功能须要重复实现,重复造轮子,浪费研发资源和运维成本。

2)设计思路:

  • 剥离各个子产品中的通用功能做为公共模块,统一进行维护管理,而后为各个子产品提供服务。
  • 公共模块的设计须要充分调研各个子产品的诉求。对于通用诉求,抽象出标准功能;对于拓展诉求,提供配置化功能;对于个性诉求,由子产品自行实现。

3)落地成果:


三、组件/插件化开发
1)需求背景:
若是说前两部分的模块化设计是对产品经理能力的考验,那这部份内容更可能是对开发人员的要求。

下面介绍咱们在平常工做中遇到过三个问题场景:
a、产品设计时,须要新增一个输入框,要求是:属于必填项、内容格式限制中英文、长度限制255字符。

需求很简单,可是每次评审时,产品经理都得给研发说明若是为空时怎么提示、内容不符合格式要求时怎么提示、长度超过限制时怎么处理,沟通成本极大,而这仅仅是整个原型设计中1%都不到的内容。

b、产品设计时,须要复用另外一个模块中的表单,表单中维护的各个表单项、表单项关联逻辑均相同。
功能彻底一致,可是研发调研后发现,原有的表单处理逻辑和业务处理逻辑强耦合,致使表单代码没法复用,须要从新独立开发。

c、在产品迭代过程当中发现存在一类需求,更新相对频繁,需求逻辑具备必定共性,并且更新不会涉及已有功能的改动。
这类需求对于开发,和公共模块之于产品相似,能够抽象为一种公共技术能力对外提供服务。好比我司常常会遇到的需求有:新增支持一种数据源、引擎新增一种任务类型等。

2)解决方案:

  • 前端沉淀标准组件库。对于一些经常使用的设计,经过组件复用来减小开发和产品的工做量;目前咱们已沉淀30+前端组件,并在持续迭代中。
  • 代码的低耦合设计。这部分要求比较虚,并且没有很是明确的边界,依赖开发经验和对业务的理解,须要持续成长。
  • 插件化设计。区分应用层代码和底层代码,底层代码进行插件化封装,可为上层不一样的应用提供支持,在支持快速迭代的同时又不会影响已有功能,这样应用层开发能够投入更多地精力去支持业务。目前已落地:数据源插件、数据同步插件、Engine插件、血缘解析插件。

3、总结思考

模块化设计是一种解决方案,并非最终目的,所以,在产品设计时不能为了模块化而模块化。尤为是产品初期,此时产品功能并不丰富,并且为了快速迭代抢占市场,并不适合投入较多的精力去作这个事情。可是一旦产品进入稳定发展期,产品经理和研发同窗都应该开始思考模块化设计在平常工做中的应用了。

模块化设计并非产品换个名称、独立作个页面就是模块化了,业务层面如何划分、模块之间如何配合、插件剥离的边界在哪,代码逻辑怎么解耦等等,这些都是须要思考的地方。


数栈是云原生—站式数据中台PaaS,咱们在github和gitee上有一个有趣的开源项目:FlinkXFlinkX是一个基于Flink的批流统一的数据同步工具,既能够采集静态的数据,也能够采集实时变化的数据,是全域、异构、批流一体的数据同步引擎。你们喜欢的话请给咱们点个star!star!star!

github开源项目:https://github.com/DTStack/flinkx

gitee开源项目:https://gitee.com/dtstack_dev_0/flinkx

相关文章
相关标签/搜索