Oinone在技术方面通过整合互联网架构和低代码技术，实现了三个独特的关键创新点（如图2-5所示）：
独立模块化的个性化定制：每个需求都可以被视为一个独立的模块，从而实现个性化定制，提高软件生产效率。此外，这些独立模块也不会影响产品的迭代和升级，为客户带来无忧的体验。
灵活的部署方式：单体部署和分布式部署的灵活切换，为企业业务的发展提供了便利，同时适用于不同规模的公司，有助于有效地节约企业成本，提升创新效率，并让互联网技术更加亲民。
低代码和无代码的结合：低无一体为不同的IT组织和业务用户提供了有效的协同工作方式，能够快速部署安全、可扩展的应用程序和解决方案，帮助企业/组织更好地管理业务流程并不断优化。
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9219.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括2c、2b）、又有第三方渠道。那么有两种设计思路： 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式，开放订单创建接口，并统一履约。 好处：简单，在3方渠道不多、且自有渠道单一，并且逻辑相识时系统结构会简单 坏处： 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时，会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹，自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道，再建立统一的订单管理系统来对接渠道订单，并完成履约 好处：交易与履约逻辑分离，对未来发展有扩展性 坏处：引入一定复杂度 我们采用的是第二套方案，整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型，交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms（libra）对himalaya-trade扩展，交易域看b2c（leo）和b2b（aries）对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名，取自黄道十二星座 交易域是多商家平台视角设计，有自身渠道必要的履约相关信息，完成自闭环。 履约域是从单一商家对接多渠道视角设计，有渠道交易订单同步后完成履约发货相关设计，完成自闭环。 履约域的合单拆单发货设计，渠道订单只能合单为履约单不可拆，履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度，而非采用两个m2m的设计。
做好企业级软件，首先得过权限这一关 在企业的IT部门沟通中，权限是避免不了。自嘲下在我们刚出来创业时，为了收获客户对我们技术能力的信任，每每与跟客户沟通时都会说我们是阿里出来的，但在权限设计这个环节不那么灵验，反而被打上了不懂B端权限设计的标签，会问很多问题。我就很奇怪难道大厂就没有内部管理系统了？大厂只有C端交易，没有B端交易？但从侧面说明权限不简单还特别重要。做好企业级软件，首先得过权限这一关。 整体介绍 对于平台运行来说，权限是必须，但我们的auth模块不是必须的，auth模块只是我们提供的一种默认实现，客户可以根据平台的spi机制进行替换。auth模块利用了平台的Hook特性做到与业务无关，在我们开发上层应用的时，是不用感知它的存在的。 auth模块涉及：功能权限、数据权限 数据权限：行权限和列权限。备注：数据权限的控制只能用于【存储模型】 表级权限：表达的语义是：是否该表可读/写（修改和新增） 列权限：表达的语义是：是否该列可读/写（修改和新增） 行权限：表达的语义是：是否对该行可读/写（修改）/删除 功能权限：表达的语义是ServerAction/Function是否可执行/展示，viewAction是否可展示，菜单是否可以显示 范围说明： 配置多个权限项的时候，取并集 配置多个角色的时候，取并集 模型设计 产品体验 Step1 创建角色 通过App Finder 切换至【权限】应用，点击新增按钮创建一个名为oinone的角色 Step2 创建数据权限项 在【权限项列表】菜单，点击【创建】按钮新增一个名为【宠物达人数据权限项】，同时宠物达人的数据权限设置为只能查看性别为男的记录 配置说明： 名称： 代表该项配置的权限的名字（必填）（必须是全系统唯一） 权限模型： 选择需要拦截的数据所在的表，即为模型，可以搜索使用 描述：对该权限项的描述 权限条件的配置： 满足全部：对条件一和条件二要同时满足的数据才能被看见 满足任一：对条件一和条件二要任意满足的数据都能被看见 读权限：对该数据是否有读取的权限 写权限：对该数据是否有修改的权限 删除权限：对该条件内的数据是否有删除的权限 Step3 为角色配置权限 编辑oinone角色，只开通oinoneDemo工程应用 选中【数据权限】选项卡点击【添加】按钮，勾选宠物达人数据权限项点击【确定】按钮 整体点击保存，回到列表页记得点击【权限生效】按钮 Step4 新建用户绑定角色 切换到用户中心模块，点击【创建】按钮填写必要信息，并在角色选中oinone权限组。 退出admin用户，用oinone登陆，权限效果： 只能看见demo模块 oinone登陆只能看到性别为男的宠物达人记录 admin用户登陆 oinone用户登陆 因为宠物达人的页面没有把性别字段放出来，我们看下数据库数据 auth模块扩展 在日常项目开发中，难免会碰到一些针对权限管理的特殊需求，或是为提升性能做的特殊逻辑。接下来我给大家介绍auth模块扩展性。 权限全局配置 对所有权限角色都做限制，而且不想让用户感知，可以实现PermissionFunApi接口，API接口实现的配置方式【只能用于支持全局的数据权限配置】 实现接口PermissionFunApi 将实现托管给SpringAOP 接口的具体实现看下图的代码 package pro.shushi.pamirs.demo.core.service; import org.springframework.stereotype.Component; import pro.shushi.pamirs.auth.api.service.PermissionFunApi; import pro.shushi.pamirs.demo.api.model.PetTalent; @Component public class PetTalentPermissionFunApi implements PermissionFunApi { @Override public String permissionDomain(Object… args) { //获取当前组织中 return "name == '张学友'"; } @Override public String nameSpace() { return PetTalent.MODEL_MODEL; } } 不参与权限控制 如果某一接口不想做权限控制，则可以在启动工程的application-dev.yml文件中配置不需要权限过滤的接口 pamirs: auth: fun-filter: – namespace: demo.PetTalent fun: queryPage 换一个没有配置宠物达人权限的用户（除管理员以外）进入系统，则也可以看到数据。注意【权限全局控制】还是生效的 API 1. 获取当前用户对该模型的行权限 Result<String> result = CommonApiFactory.getApi(AuthApi.class).canReadAccessData("Model"); 返回值为 { 'data':"name=in=('hahaha')" 'success'：true … } 用法 ： 场景：前端发起的请求都会经过权限拦截，后端代码逻辑发起的数据请求都是不经过任何权限的过滤，但是某些特殊情况需要在后端代码逻辑发起的数据请求也带上权限过滤 入参：请求的模型 出参：Result 数据结构中data会存储一段字符串，该字符串为Rsql 将该Rsql追加到wrapper中 Result<String> result = CommonApiFactory.getApi(AuthApi.class).canReadAccessData("base.UeModule"); String data=result.getData(); QueryWrapper<UeModule> wrapper = Pops.query(); wrapper.setEntity(ueModule); if (!StringUtils.isBlank(data)) { wrapper.apply(data); }
1. 流程触发 新增的流程设计页面默认包含两个节点，一个是流程的触发节点：确定流程开始的条件；另一个是流程结束的节点。 流程触发方式有模型触发、定时触发、日期触发三种方式，未设置流程触发方式时无法继续添加后续流程节点，同时无法进行流程发布，如左下图。触发方式设置完成后，可从左侧菜单栏拖入或流程箭头中的加号点击添加节点动作，如右下图。 1.1 模型触发 模型触发适用于模型中的数据字段变化开始流程的场景，比如员工请假审批流程。 模型触发的场景有数据的增删改，也可以对模型中的单个或多个字段进行条件筛选，若包含更新数据的场景可以设置选择更新字段，只有设置的字段更新才会触发流程，若不设置选择更新字段或者筛选条件，则模型中任一字段发生设置场景的变化时都会触发流程。 1.2 定时触发 定时触发适用于周期性调用流程的场景，比如仓库周期性盘点的流程。 需要设置一个流程第一次执行的时间，配置好循环的周期间隔。特殊的是选择周为周期时，当前周选中的日期也会执行流程。例：开始时间：2022-01-14（周四） 循环周期间隔：1周 自定义设置为周一到周五，则2022-01-15（本周五）也会执行流程操作。 1.3 日期触发 日期触发适用于模型中的日期时间字段引发流程的场景，比如给员工发生日祝福短信的流程。 设置日期触发时，若指定字段只包含日期，则必须要指定时刻，如左下图。例如给员工发生日祝福短信时根据模型中的员工生日数据获取到了执行流程的日期，需要制定开始该流程执行的具体时刻。若指定字段包含日期和时间，则不填写指定时刻时默认按照字段中的时刻开始执行流程，如右下图。例如办理业务后短信回访收集评价时根据模型中的业务完成时间，立即或延时发送短息。
在中后台业务场景中，大部分的请求时候是可以被枚举的，比如创建、删除、更新、查询。在上文中，我们讲了httpClient如何自定义请求，来实现自己的业务诉求。本文中讲到的Request是离业务更近一步的封装，他提供了开箱即用的API，比如insertOne、updateOne，它是基于HttpClient做的二次封装，当你熟悉Request时，在中后台的业务场景中，所有的业务接口自定义将事半功倍。 一、Request详细介绍 元数据-model 获取模型实例 import { getModel } from '@kunlun/dependencies' getModel('modelName'); 图4-2-5-1 获取模型实例 清除所有缓存的模型 import { cleanModelCache } from '@kunlun/dependencies' cleanModelCache(); 图4-2-5-2 清除所有缓存的模型 元数据-module 获取应用实例，包含应用入口和菜单 import { queryModuleByName } from '@kunlun/dependencies' queryModuleByName('moduleName') 图4-2-5-3 获取应用实例 查询当前用户所有的应用 import { loadModules } from '@kunlun/dependencies' loadModules() 图4-2-5-4 查询当前用户所有的应用 query 分页查询 import { queryPage } from '@kunlun/dependencies' queryPage(modelName, { pageSize: 15, // 一次查询几条 currentPage, 1, // 当前页码 condition?: '' // 查询条件 maxDepth?: 1, // 查几层模型出来，如果有2，会把所有查询字段的关系字段都查出来 sort?: []; // 排序规则 }, fields, variables, context) 图4-2-5-5 分页查询 自定义分页查询-可自定义后端接口查询数据 import { customQueryPage } from '@kunlun/dependencies' customQueryPage(modelName, methodName, { pageSize: 15, // 一次查询几条 currentPage, 1, // 当前页码 condition?: '' // 查询条件 maxDepth?: 1, // 查几层模型出来，如果有2，会把所有查询字段的关系字段都查出来 sort?: []; // 排序规则 }, fields, variables, context) 图4-2-5-6 自定义分页查询 查询一条-根据params匹配出一条数据 import { queryOne } from '@kunlun/dependencies' customQueryPage(modelName, params, fields, variables, context) 图4-2-5-7 根据params匹配出一条数据 自定义查询 import { customQuery } from '@kunlun/dependencies' customQuery(methodName, modelName, record, fields, variables, context) 图4-2-5-8 自定义查询 update import { updateOne } from '@kunlun/dependencies' updateOne(modelName, record, fields, variables, context) 图4-2-5-9 update insert import { insertOne } from '@kunlun/dependencies' insertOne(modelName, record, fields, variables, context) 图4-2-5-10 insert delete import { deleteOne } from '@kunlun/dependencies'…
介绍Model相关元数据，以及对应代码注解方式。大家还是可以通读并练习每种不同的使用方式，这个是oinone的设计精华所在。当您不知道如何配置模型、字段、模型间的关系、以及枚举都可以到这里找到。 一、模型元数据 安装与更新 使用@Model.model来配置模型的不可变更编码。模型一旦安装，无法在对该模型编码值进行修改，之后的模型配置更新会依据该编码进行查找并更新；如果仍然修改该注解的配置值，则系统会将该模型识别为新模型，存储模型会创建新的数据库表，而原表将会rename为废弃表。 如果模型配置了@Base注解，表明在studio中该模型配置不可变更；如果字段配置了@Base注解，表明在studio中该字段配置不可变更。 注解配置 模型类必需使用@Model注解来标识当前类为模型类。 可以使用@Model.model、@Fun注解模型的模型编码（也表示命名空间），先取@Model.model注解值，若为空则取@Fun注解值，若皆为空则取全限定类名。 模型元信息 模型的priority，当展示模型定义列表时，使用priority配置来对模型进行排序。 模型的ordering，使用ordering属性来配置该模型的数据列表的默认排序。 模型元信息继承形式： 不继承（N） 同编码以子模型为准（C） 同编码以父模型为准（P） 父子需保持一致，子模型可缺省（P=C） 注意：模型上配置的索引和唯一索引不会继承，所以需要在子模型重新定义。数据表的表名、表备注和表编码最终以父模型配置为准；扩展继承父子模型字段编码一致时，数据表字段定义以父模型配置为准。 名称 描述 抽象继承 同表继承 代理继承 多表继承 基本信息 displayName 显示名称 N N N N summary 描述摘要 N N N N label 数据标题 N N N N check 模型校验方法 N N N N rule 模型校验表达式 N N N N 模型编码 model 模型编码 N N N N 高级特性 name 技术名称 N N N N table 逻辑数据表名 N P=C P=C N type 模型类型 N N N N chain 是否是链式模型 N N N N index 索引 N N N N unique 唯一索引 N N N N managed 需要数据管理器 N N N N priority 优先级，默认100 N N N N ordering 模型查询数据排序 N N N N relationship 是否是多对多关系模型 N N N N inherited 多重继承 N N N N unInheritedFields 不从父类继承的字段 N N N N unInheritedFunctions 不从父类继承的函数 N N N N 高级特性-数据源 dsKey 数据源 N P=C P=C N 高级特性-持久化 logicDelete 是否逻辑删除 P P P N logicDeleteColumn 逻辑删除字段 P P P N logicDeleteValue 逻辑删除状态值 P P P N logicNotDeleteValue 非逻辑删除状态值 P P P N underCamel 字段是否驼峰下划线映射 P P P N capitalMode 字段是否大小写映射…
