/dsl-aggregation

参考 mysql 的关联查询与 view 以及 mongodb 的 aggregation 设计 lowcode 数据逻辑处理部分的词法

Primary LanguageJavaScript

dsl-aggregation

本项目主要用于整理:

  1. 常用数据库中的查询语句设计（mysql 的 SQL，mongodb 的操作语法）
  2. 市面上常用的 nocode/lowcode 平台内置的 DSL （这里主要以 简道云 为参考样板）
  3. 基于上述整理并设计满足自身业务需求的 DSL

以用于对应业务系统的低代码平台搭建参考

行业简析

目前各类 nocode 或 lowcode 平台已经被广泛用于生活和生产中:

  1. 小到社区拼团，大到工厂流水线管理，该类平台基本可以覆盖常见的 信息收集/汇总/展示 处理场景
  2. 相较于传统it开发模式，其较低的上手门槛以及对业务的适配灵活性也是其能被广泛应用的关键
  3. 可显著降低部分领域的研发成本（资金/人力/时间）

但在具备上述优势的同时，当前的 nocode/lowcode 平台也有着以下的问题:

  1. 适配场景有限，一般局限于 表单/报表/流程 这些领域
  2. 为了降低使用门槛，部分地方的设计并不利于业务逻辑的维护

但总体上来说瑕不掩瑜，低代码平台能取得市场上的成功也是其对应的产品设计较好满足当前的 生活/生产需求 的体现

较为详细的分析会放在 案例解析 部分

相关困境

由于笔者的大部分产研工作属于定制化较强的 toC场景，为了加快业务逻辑部分的开发效率：

  1. 自19年开始尝试用 nocode/lowcode 的方式处理部分较为通用的业务逻辑，为此也搭建了自身业务方向的低代码框架
  2. 对市面上已有的 nocode/lowcode 平台和开发框架做调研与汇总

其中对已有平台和框架的调研的初心是为了找出能直接投入到生产的工具，但实际使用遇到了以下困境：

  1. 以 表单/报表/流程 为主要服务对象的低代码平台其数据模型层与UI层高度耦合，虽在特定领域方向使用便捷，但相较于传统开发模式在包含较多定制化需求的 toC场景 下并不能明显提高开发效率（甚至是负收益）
  2. 以 CMS 场景为主要服务对象的框架（例如strapi）则在权限控制的颗粒度上以及用户系统的治理上存在较难适配的问题，在 toC场景 下其额外的适配工作抵消了其本身的便捷

造成上述困境的根本原因在于无论是低代码平台还是CMS框架，其本身为了适配特定的业务方向而做了诸多的定制化工作，这些定制化的适配给其服务的目标业务方向提供了极大的便利，但 汝之蜜糖，吾之砒霜，当想将这些平台或是框架直接用于其他的领域或业务方向时也会因为这些定制化的内容造成困境。这也是笔者进行自建框架的主要原因。

TIPS: 调研平台或开发工具中的设计思路对自建框架是有诸多启发的。

设计目标

截止到编写本文前（2022），笔者已经完成了自建框架中的数据模型管理与模型直接接口的相关工作，并在实际生产中用该框架支撑了十多个产品，本次的设计目标为：

  1. 对 数据的加工逻辑 做进一步的抽象封装，创建能在该方向便捷使用的 DSL
  2. 同时也要考虑为 数据的加工逻辑 提供更好的面板支持（版本管理/调试界面等，该部分亦会对 DSL 的设计本身有一定影响）