0代码引擎(二)-架构设计

简介

    业务人员熟悉业务，开发人员熟悉软件开发技术，两者存在鸿沟，需要系统分析员做转换，理解业务，转化为软件设计，再由软件工程师实现，然后测试，最后发布，这是软件工程的整个流程，对于简单的业务，或者客户定制需求，成本过高。0代码引擎填平业务人员和开发人员之间的鸿沟，业务人员通过拖拉拽实现业务代码，代码是生成的，可靠和经验证的，开发人员开发中间件，通用组件和0代码引擎本身，大大减少成本，开发和交付周期。

规划特性与发布计划

v1  0代码-业务逻辑

v2  0代码-集成中间件

v3  0代码-AI，语音/文本提取业务和实体

术语/关键词

• 4+1视图
• 元模型/元素据驱动
• 贫血模型/充血模型

充血模型（Domain Driven Design）是一种面向对象的软件设计方法，业务逻辑封装在业务对象中，业务对象各施其职，协同互动完成业务，业务对象重用性高，业务变更只影响相关业务对象。

贫血模型（Anemic Domain Model）是一种将数据与行为分离的模型，数据由实体对象持有，而行为则由应用服务提供，相对充血模型，整个业务逻辑位于应用服务，粒度大没有可用性，业务稍有变化，一大堆应用服务需要修改

参考资料

EMF 《EMF: Eclipse Modeling Framework 2nd》

技术架构

上图是技术架构图，分5块，模型设计；业务逻辑设计；代码生成；整合中间件/技术框架；编译和打包

元模型 负责元模型构建， 包括

1 模型类，包括应用服务，业务对象，实体；

2 逻辑  协同应用服务，业务对象和实体的互动，完成业务脚本或规则

3 关联  关联导入类

代码生成 元模型生成代码，包括元模型生成业务模型代码，业务逻辑代码，持久层代码，导入类关联

代码编译打包 平台使用maven编译和打包

代码扫描器 用户引入代码资源包

整合中间件/技术框架 中间件整合，利用spring boot的注解和aop机制，参数化模板生成集成代码，实际也是代码生成

运行架构

上图运行架构图，展示平台的执行组件，组件调用关系，关注代码和规则高吞吐，大规模执行，走执行服务主要是规则，以业务为事实，规则做出决策

> 规则资源中心(CRC)  存储jar包，按不同主题，发布，测试等，支持版本

> 规则执行服务(CES)  注册到CDI，分配执行标的

> 资源目录/索引(CDI)  搜索jar执行器的分配；distro(AP)/reids 服务/规则执行分配复制

> 网关(CSG) 职责是选择合适的执行服务

指标: 亿级执行量，百万级代码和规则包

逻辑架构

下图是0代码引擎的逻辑架构

执行服务 rpc执行代码，通常用于规则；业务逻辑直接嵌入业务类和业务对象

资源库 存储模型，jar包；搜索

建模

  模型(meta-model) 应用服务类，业务对象，实体

  logic  协调代码实现业务脚本，建模的一部分，生为成代码

codegen 代码生成器，支持ecore模型生成，模板生成

扫描器 扫描用户指定的目录，提取类信息，并注册，后续可用于业务逻辑构建

**代码和规则在本平台是同一资源，区别是，代码是实现业务逻辑， 应用服务和BO协调互动实现，内嵌到业务类的方法；规则实现业务决策，以业务事实为事实，作出决策，没有应用服务和BO参与；规则通常实现为工具静态类，由执行服务执行

场景

本节介绍场景，描述参与角色的职责和交付物

新建应用

参与角色：业务人员

应用是本平台管理单位，对应业务平台的应用，业务人员构建应用，平台构建maven工程，以maven工程管理0代码

准备资源

参与角色：业务人员，开发人员

业务人员和开发人员依据业务脚本，导入所需的包，工具类等，该操作整个过程中任何时候可以进行，元模型可以拷贝到新应用，但平台视为不同的两份模型，任何时候业务人员可以载入新资源

建模

参与角色：业务人员

业务人员构建元模型，包括应用服务类，业务对象，实体，以及关联关系，业务逻辑，保存到模型库

生成代码

参与角色：业务人员

建模完成后，业务人员生成代码，包括3部分，元模型生成，逻辑代码生成，中间件集成代码生成

建模和生成代码是交替迭代的过程

编译打包和测试

参与角色：业务人员

业务逻辑完成后，业务人员打包，发布到测试桶，待测试人员测试

发布

参与角色：业务人员

测试后的jar包，发布到maven库，若是可执行的包，如spring boot jar，提供下载，不发布到maven