在作企业服务类(ToB)的产品时,咱们常常会遇到以下场景:html
每一个客户拿着他们的需求清单,来咨询咱们的产品是否可知足他们的诉求。如图所示:前端
每一个客户的需求有重叠的内容,也有不同的内容,而这些需求,在某一领域均具备较强的通用性。git
如何知足这些客户需求的同时又能使各个需求沉淀为标准功能,而不只仅是为了交付项目?这成为ToB类产品经理思考最多的问题。github
为支撑客户诉求,基本的作法是抽象各个需求,落地为标准功能,将各个功能拼装成一个产品。可是一段时间后你们就会发现功能越堆越多、产品越作越庞大,可是用户体验却愈来愈差,产品开发维护愈来愈困难。
如何既能知足客户诉求,又能解决产品存在的这些问题?模块化设计是一个方向。后面咱们展开介绍下,数栈在模块化设计方面的一些经验供参考。算法
(一)目的框架
(二)落地经验
模块化设计在数栈平台的落地实施,从大到小主要分为下面三种方式:运维
一、子产品化
1)需求背景:
每一个客户,甚至同一个客户在不一样阶段,对数据中台的理解都不尽相同。ide
2)设计思路:模块化
3)落地成果:
数栈做为一款数据中台产品,其中包含了:离线开发、实时开发、算法开发、数据服务、数据资产、数据质量、智能标签等子产品,每一个子产品可解决不一样的业务场景诉求,并支持独立、组合部署。工具
二、公共模块
1)需求背景:
数栈的各个模块独立化成子产品后,虽然能够解决不一样的业务场景诉求,可是在数据中台这个框架内,仍然会存在一些相同的基础功能诉求,好比用户体系、数据源管理、任务运维等。若是每一个子产品内部独立实现,会存在两个问题:
2)设计思路:
3)落地成果:
三、组件/插件化开发
1)需求背景:
若是说前两部分的模块化设计是对产品经理能力的考验,那这部份内容更可能是对开发人员的要求。
下面介绍咱们在平常工做中遇到过三个问题场景:
a、产品设计时,须要新增一个输入框,要求是:属于必填项、内容格式限制中英文、长度限制255字符。
需求很简单,可是每次评审时,产品经理都得给研发说明若是为空时怎么提示、内容不符合格式要求时怎么提示、长度超过限制时怎么处理,沟通成本极大,而这仅仅是整个原型设计中1%都不到的内容。
b、产品设计时,须要复用另外一个模块中的表单,表单中维护的各个表单项、表单项关联逻辑均相同。
功能彻底一致,可是研发调研后发现,原有的表单处理逻辑和业务处理逻辑强耦合,致使表单代码没法复用,须要从新独立开发。
c、在产品迭代过程当中发现存在一类需求,更新相对频繁,需求逻辑具备必定共性,并且更新不会涉及已有功能的改动。
这类需求对于开发,和公共模块之于产品相似,能够抽象为一种公共技术能力对外提供服务。好比我司常常会遇到的需求有:新增支持一种数据源、引擎新增一种任务类型等。
2)解决方案:
模块化设计是一种解决方案,并非最终目的,所以,在产品设计时不能为了模块化而模块化。尤为是产品初期,此时产品功能并不丰富,并且为了快速迭代抢占市场,并不适合投入较多的精力去作这个事情。可是一旦产品进入稳定发展期,产品经理和研发同窗都应该开始思考模块化设计在平常工做中的应用了。
模块化设计并非产品换个名称、独立作个页面就是模块化了,业务层面如何划分、模块之间如何配合、插件剥离的边界在哪,代码逻辑怎么解耦等等,这些都是须要思考的地方。
数栈是云原生—站式数据中台PaaS,咱们在github和gitee上有一个有趣的开源项目:FlinkX,FlinkX是一个基于Flink的批流统一的数据同步工具,既能够采集静态的数据,也能够采集实时变化的数据,是全域、异构、批流一体的数据同步引擎。你们喜欢的话请给咱们点个star!star!star!
github开源项目:https://github.com/DTStack/flinkx
gitee开源项目:https://gitee.com/dtstack_dev_0/flinkx