从业务角度出发来构建低代码应用

时间：2022-12-27 17:55:42

低代码确实会少写代码，其概念也不同于复制修改的模板技术，不同于开箱即用的全站配置，不同于趋近于零代码的图形化编程。如果低代码是可以普遍推广的，那么就应该是普遍被业务人员所接受的。那么站在业务人员的视角，构建低代码应用的思路到底是怎样的呢？

业务背景

业务人员应熟悉并使用

  • 协同办公：包括组织结构、岗位职责、消息通知，复杂的包括电子邮件、VPN、文档、机器人助手等
  • 数据信息：包括数据表单、数据库，复杂的包括数据规范/标准，数据交换接口等
  • 业务流程：包括各种申请、审批要求，复杂的涉及多版本流程、伙伴流程（如供应链流程）等
  • 专业应用：包括数据模型、分析算法，复杂的包括专业软件、AI计算等

其中系统办公和业务流程是很多组织的共有部分，数据信息和专业应用则各有不同。

应用建设

建设思路

（1）共有部分建设 要开发低代码应用，就需要有一个覆盖组织、数据和流程的应用基座。 成品选型：成品选型包括钉钉、飞书、企业微信，其中使用体验较好的听说是飞书。 自建选型：如果要重新构建，也有诸多选择，后续章节列出。有些可以直接集成使用，有些需要做一些二次开发。

（2）专业部分建设 专业部分的大型软件按下不提，剩余部分通过第三方服务或者自建服务实现。 其中第三方服务主要涉及数据交换，自建服务实施领域工程。

自建选型

前端及用户可见部分

  • 身份认证

  • 消息流

    • goeasy 企业级Websocket和IM即时通讯
    • MobileIMSDK 专为移动端开发的原创IM通信层框架

  • 文档

    • notesnook An end-to-end encrypted note taking alternative to Evernote.
    • mrdoc 自托管、私有部署的在线文档管理系统和知识库

  • 流程

    • liteflow 轻量，快速，稳定可编排的组件式规则引擎
    • activiti Open Source Business Automation

  • 表单设计

  • 图形分析

后端存储、计算和第三方服务

  • 数据库服务
  • 文件服务
  • 自有函数式 API
  • 第三方 API 服务
  • 短信服务
  • 手机消息推送

基本上云服务商都提供了。

低代码与模型

领域特定语言 DSL

DSLs implemented via an independent interpreter or compiler are known as External Domain Specific Languages. Well known examples include LaTeX or AWK. A separate category known as Embedded (or Internal) Domain Specific Languages are typically implemented within a host language as a library and tend to be limited to the syntax of the host language, though this depends on host language capabilities.

DSL 根据实现一般分为内部（Embedded / Internal）和独立（External）两种。 内部 DSL 依托于某种语言运行，需要学习或者使用某种编程语言。 独立 DSL 不依托于其他编程语言，有独立的编译器。 不管实现方式如何，其首要的关注点领域模型。

领域模型 Domain-Model

组织结构

常见的组织结构

  • 功能型组织结构（functional structure）（适合专业型/固定业务类型组织）
  • 多层功能型组织结构（multi-divisional structure）
  • 矩阵型组织结构（matrix structure）
  • 区域型组织结构（gergraphic structrue）(大型组织)
  • 产品型组织结构 (product team structure)（产品团队）

常见的访问控制

  • 基于角色的权限控制（RBAC，Role-Based Access Control）
  • 自主访问控制（DAC，Discretionary Access Control）
  • 强制访问控制（MAC，Mandatory Access Control）
  • 基于属性的权限验证（ABAC，Attribute-Based Access Control）

组织机构和访问控制是密切结合的。 对于复杂组织，需要考虑用户-组织-部门-岗位-角色-权限六种要素。 成品的办公底座，通常会选择一种方式来实现。对于小微型团队来说，显得过于复杂。对于大型公司来说，又显得不足。

信息流模型

  • 表单模型
    • 数据项：数据项是数据对象的组成元素，名称可能不同，但常见类型基本一致，可以约定后描述。数据项之间存在计算、约束规则。
      • 示例表示：不需要专业知识，只需要写出示例，常例、特殊例子，由系统判定
      • 类型表示：需要熟悉约定的数据类型，指定即可，配置更加精确
    • 数据对象（类）：数据对象对照业务实体，由数据项组成。数据对象之间存在关联关系。
      • 名称表示：符合常规习惯或者约定，表达唯一语义
    • 数据表单：日常业务中常见的数据接口，通常由一个或以上的数据对象组成。
      • 名称表示：符合组织的数据规范或者一致习惯
      • 痕迹表示：包含表单操作时间、人员的痕迹
  • 流程模型：流程引擎是使用 DSL 较早且滥用 DSL 较多的，自动流程和审批流程使用较多。

信息模型具有一定的适应性，同时也需要匹配组织规模。 对于小型组织或者小规模的业务来说，数据表单为主的模型即可覆盖。 对于大型组织或者复杂的业务来说，聘用专业的IT人员，会使用数据集为主的模型。

专业模型

  • 管理模型：
    • 人员：员工招聘、入职、调动、离职、培训、奖惩等过程
    • 物资/设备：采购、出入库、使用、维修、报废等过程
    • 财务：预算、合同、资金、发票相关过程
    • 研发：调研、分析、设计、生产、检验、试用过程
  • 业务模型：对于业务数据进行预处理、计算和分析，满足生产、研判的需要，通常需要专业领域的计算服务或者跨学科的基础服务支持，比如科学计算等。

管理模型在大多数企业中均存在，但更加深度的模型则各有千秋。但不论如何，大致都可以归到数学模型中来。

小结

如果我们将低代码理解为用少量代码构建应用，而不是通过图形化、融媒体替代构建应用，那么低代码或许最接近的就是（DSL，domain-specific languages），首当其冲的研究对象是领域模型。将领域模型搞清楚，通过简洁清晰的表示来表达并构建应用，这不仅是低代码要做的事情，也是未来AI构建应用的方向。后续章节将继续探讨领域模型与应用之间的低代码之路。

标签：

相关文章