一种基于 “领域模型” 的建站模式

前端发展至今,研发同学们为了解决提效问题,衍生出多种建站模模式,核心思路是:把多而重复的工作尽可能磨平,只针对定制化需求进行开发。这里分享一种新的建站模式 - 通过构建多个 领域模型 搭建系统。

现有方案一:页端建站。

这种方案是很多活动站点的方式。通过大量的前端通用组件,应对活动需求时,通过这些组件的瓶装,组装成站点,这种方式很好的解决纯前端站点的搭建。

图1.1

这种方案有一个较大的局限性,更多只服务于 “页端多变,后端相对固定”的场景,大量使用在 “活动促销页构建” 的场景。但对于后端多变的业务需求,还是需要定制化开发后端。

现有方案二:serverless 云函数孕育而生

程序员总是懒的,既然方案一的后端能力比较薄弱,serverless 云函数的思路随即诞生,在 18~19 年开始逐渐落地到各种业务场景上。通过建站系统配合云函数,可以快速的响应并交付需求

这种方案几乎可以解决 80% 的通用运营需求:

  1. 建站体系通过 model -> view 的模式,根据db表直接映射成运用站点。
  2. 同时提供各种事件钩子,用于完成各种定制化逻辑。
  3. 通过云函数系统,在线完成各种业务逻辑。

局限性: 针对剩余 20% 领域性较强的需求,并不是太适用。这里用触达系统来举例,因为触达系统需要描述比较复杂的货品,需要描述各种触达规则,并且有各种离线逻辑。

面对定制化程度高,用这种方案去做没能达到实质性的提效。

方案三:“领域建模” 建站方案

还是用回触达系统来作为例子,针对于触达领域,我们可以抽象出 “人-货-场” 三种板块,所有触达都是:把特定货品基于特定场景推送给特定人。因此,我们可以推导出以下3个要做的事情:

  1. 沉淀系统可复用能力。
  2. 沉淀业务可复用能力。
  3. 支持灵活定制化建站。

算子服务 - 可复用的系统能力

在触达领域,最小的粒度即为 ”算子“(其他系统需要各自抽象),它是描述”人货场“的最小单元,对于触达领域的系统而言他就是最小系统粒度。

每个算子都是一个垂直的结构,由前端组件、服务端逻辑、离线逻辑、数据结构,存储场景 组成。每个算子并不是一个简单的前端组件,可以理解它是一个比微服务更微的微服务。通过各个算子的拼装,即可拼装成系统交付客户。

同时,客户会有这种各种各样的定制化需求,这里通过页面钩子,事件钩子,服务端钩子去解决。

领域模型 - 可复用的业务能力

有了算子服务已经具备了建站的能力,但是这样的提效是不够极致的,因为我们在实际面对客户的情况里,有相同业务诉求的客户,他们需要的 80% 业务能力都是一样的,只有 20% 的定制化部分(如手管和wifi 都需要消息推送,他们需要的能力 80% 都是相同的)。我们需要做到极致的提效,就需要把这 80% 的重复能力给沉淀下来。这里就需要引入 “领域模型” 的概念。

所谓领域模型,它描述了一种通用业务能力,如:消息推送,云指令,端内触达,动态资讯等等。它规定了在业务能力里,需要勇夺哪些算子服务,这些算子服务如何组装。

客户需要把特定的消息内容(货),基于特定事件(场),特定业务条件(场),推送给指定guid的人群(人),在客户端以通知栏的形式展现。基于这个需求,我们可以抽象出一种叫“消息推送”的业务能力,进而通过领域模型去表达。我们分别从货品算子库里面调取“消息内容算子”,从场景算字库里面调取“触发点算子”、“业务条件算子”,从人群算子库里面调取“人群定向算子”,以为切片的方式平行组装,而又因为米格算子都是一个垂直的结构,因此,分层去看,所有算子组装起来后,就描述好了整个业务的 UI层,服务层,离线层、以及存储层。透过模型解析器,即可生成如右图所示的系统。而同一个模型可以重复生成多个系统,这样面对有相同业务诉求的客户,我们即可做到比较极致的提效。

有了算子,研发同学知道系统能支持什么。有了领域模型,业务同学知道我们能卖什么。可以说,有了领域模型,项目的产品化才具备可操作性。

面向对象建站 - 平衡通用与定制化

到这里我们能通过领域模型沉淀80%的业务通用能力,剩余的 20% 我们则参考面相对象的设计模式来作为建站机制。面向对象相信大家都比较熟悉,它有3个特征:封装、继承、多态。

我们还是类比刚刚消息推送的例子,一个领域模型好比是一个类,模型内封装好的算子相当于是类的属性,生成系统的过程就好比是实例化的过程,系统除了可以继承模型的算子以外,还可以根据客户的定制化需求动态增减算子,而前面提到每个算子都有各种各样的钩子,这意味着算子是可重载的,页面钩子支持换皮,事件支持定制化交互,后端钩子支持写定制化逻辑。

这样动态增减算子,加上算子可重载,可有效应对客户剩余 20% 的定制化需求。

整体解决方案:算子服务 + 领域模型 + 面向对象

  1. 通过算子服务沉淀可复用的系统能力,落地到算子库。(提效)
  2. 通过领域模型沉淀可复用的业务能力,落地到领域模型库。(提效)
  3. 通过面向对象模式,来作为系统生成机制。(灵活)

欢迎交流 ~~~~~~~

本站文章资源均来源自网络,除非特别声明,否则均不代表站方观点,并仅供查阅,不作为任何参考依据!
如有侵权请及时跟我们联系,本站将及时删除!
如遇版权问题,请查看 本站版权声明
THE END
分享
二维码
海报
一种基于 “领域模型” 的建站模式
前端发展至今,研发同学们为了解决提效问题,衍生出多种建站模模式,核心思路是:把多而重复的工作尽可能磨平,只针对定制化需求进行开发。这里分享一种新的建站模式 - ...
<<上一篇
下一篇>>