Oinone在技术方面通过整合互联网架构和低代码技术，实现了三个独特的关键创新点（如图2-5所示）：
独立模块化的个性化定制：每个需求都可以被视为一个独立的模块，从而实现个性化定制，提高软件生产效率。此外，这些独立模块也不会影响产品的迭代和升级，为客户带来无忧的体验。
灵活的部署方式：单体部署和分布式部署的灵活切换，为企业业务的发展提供了便利，同时适用于不同规模的公司，有助于有效地节约企业成本，提升创新效率，并让互联网技术更加亲民。
低代码和无代码的结合：低无一体为不同的IT组织和业务用户提供了有效的协同工作方式，能够快速部署安全、可扩展的应用程序和解决方案，帮助企业/组织更好地管理业务流程并不断优化。
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9219.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
PamirsPartner作为商业关系与商业行为的主体，那么PamirsPartner间的关系如何描述，本文将介绍两种常见的设计思路，从思维和实现两方面进行对比，给出oinone为啥选择关系设计模式的原因。 一、两种设计模式对比 设计模式思路介绍 角色设计模式思路介绍 从产品角度枚举所有商业角色，每个商业角色对应一个派生的商业主体，并把主体间的关系类型进行整理。 图5-4-1 角色设计模式 关系设计模式思路介绍 从产品角度枚举所有商业角色，每个商业角色对应一个派生的主体间商业关系 图5-4-2 关系设计模式 设计模式对应实现介绍 角色设计模式实现介绍 不单商业主体需要扩展，关系也要额外维护，可以是字段或是关系表。一般M2O和O2M字段维护，M2M关系表维护。 创建合同场景中甲方选择【商业主体A】，乙方必须是【商业主体A】有关联的经销商、分销商、零售商、供应商等，则在角色设计模式下就非常麻烦，因为关系都是独立维护的 图5-4-3 角色设计模式实现介绍 关系设计模式实现介绍 只需维护商业关系扩展 同时在设计上收敛了商业关系，统一管理应对不同场景都比较从容 图5-4-4 关系设计模式实现介绍 二、oinone商业关系的默认实现 首先oinone的商业关系选择关系设计模式 其次模型上采用多表继承模式，父模型上维护核心字段，子模型维护个性化字段。
一、后端基础环境准备 安装JDK1.8 ，高于1.8_221以上（下载地址见书籍【附件一】） 打开Windows环境变量配置页 此电脑 => 右键属性 => 系统高级设置 => 环境变量 配置环境变量 在用户环境变量中新建变量为JAVA_HOME的项,值为JDK安装之后的路径 图3-1-27 新建环境变量JAVA_HOM 编辑变量为Path的项添加一个值%JAVA_HOME%\bin 图3-1-28 添加一个环境变量值%JAVA_HOME%\\bin PowerShell或者CMD中验证，输出类似信息为安装配置成功 图3-1-29 验证JAVA是否安装成功 安装 Apache Maven 3.8+ （下载地址见书籍【附件一】） 删除Maven安装目录下的conf/settings.xml 配置mvn的settings，下载附件settings-open.xml，并重命名为settings.xml,建议直接放在【C:\Users\你的用户名.m2】下面。下载地址见oinone开源社区群公告，也可以联系oinone合作伙伴或服务人员 配置环境变量 在用户环境变量中新建变量为M2_HOME的项,值为Maven安装路径 图3-1-30 新建变量M2_HOME 编辑变量为Path的项添加一个值%M2_HOME%\bin 图3-1-31 添加一个值%M2_HOME%\\bin 验证 图3-1-32 验证Maven是否安装成功 安装 Jetbrains IDEA （下载地址见书籍【附件一】） 插件安装 下载地址 密码: mdji 如果IDEA安装了Lombok插件,请禁用Lombok插件 点击菜单项File => Settings => Plugins 图3-1-33 插件管理页面操作示意 下载插件包 (联系Oinone官方客服) 图3-1-35 操作指引 图3-1-36 操作指引 安装MySQL 8 （下载地址见书籍【附件一】） 解压下载的ZIP安装包, 复制到自定义安装目录 设置环境变量 MYSQL_BASE_DIR 提换成MySQL安装目录路径 把 %MYSQL_BASE_DIR%\bin 加入到系统环境变量中 在PowerShell中可以使用 Get-Command mysqld 命令验证环境变量是否配置成功，执行成功输出mysqld的所在路径 初始化 在命令行中执行 mysqld –initialize-insecure –user=mysql 安装 mysqld -install 启动MySQL服务 mysqld -install 设置root用户密码 alter user \’root\’@\’localhost\’ identified with mysql_native_password by \’oinone\’; flush privileges; 安装DB GUI工具 Datagrip、MySQLWorkbench、DBEaver 选其一 ### 安装Git （下载地址见书籍【附件一】） 安装GraphQL测试工具Insomnia（下载地址见书籍【附件一】） 安装RocketMQ（下载地址见书籍【附件一】） 修改安装目录下bin中对应文件的默认配置 a. runserver.cmd文件内容 -Xms2g -Xmx2g为 -Xms1g -Xmx1g b. runbroker.cmd文件内容 -Xms2g -Xmx2g为 -Xms1g -Xmx1g，以及-XX:G1HeapRegionSize=1m 启动RocketMQ NameServer命令 RocketMQ安装目录\bin\mqnamesrv.cmd start 启动RocketMQ Broker命令 RocketMQ安装目录\bin\mqbroker.cmd -n localhost:9876 停止 RocketMQ命令 mqshutdown.cmd broker mqshutdown.cmd namesrv 安装ElasticSearch 版本 8.4.1（下载地址见书籍【附件一】） （非必须） ES运行时需要JDK18及以上版本JDK运行环境, ES安装包中包含了一个JDK18版本 set JAVA_HOME=ES安装路径\jdk 启动 ES安装路径\bin\elasticsearch.bat 停止 ctrl+c 或者关闭cmd、PowerShell的窗口 安装Redis （下载地址见书籍【附件一】） 解压安装包到安装目录 在PowerShell进入到Redis安装目录 在PowerShell中执行.\redis-server.exe，输出图中类似信息（如下图3-35所示）： 图3-1-37 验证redis是否安装成功 新开PowerShell窗口, 进入到Redis安装目录, 执行 .\redis-cli.exe回车，输入 ping 回车输出 PONG即表示Redis安装成功 图3-1-38 验证redis是否安装成功 Zookeeper安装（下载地址见书籍【附件一】） 解压安装, 在 PowerShell中执行 tar zxvf 安装包路径(tar.gz包) -C Zk安装目录 进入 Zk安装目录\conf\ 复制 zoo_sample.cfg文件为 zoo.cfg 修改zoo.cfg文件的内容 （其中dataDir需要自己设定） tickTime=2000…
多语言是国际化中大家最常面对的问题，我们需要对应用的页面结构元素进行翻译，也需要对系统内容进行翻译比如：菜单、数据字典等，甚至还会业务数据进行翻译。但不管什么翻译需求，我们在实现上基本可以归类为前端翻译和后端翻译。前端翻译顾名思义是在前端根据用户选择语言对内容进行翻译，反之就是后端翻译。本文会带着大家了解oinone的前端翻译与后端翻译 准备工作 pamirs-demo-boot的pom文件中引入pamirs-translate包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-translate</artifactId> </dependency> pamirs-demo-boot的application-dev.yml文件中增加配置pamirs.boot.modules增加translate，即在启动模块中增加translate模块 pamirs: boot: modules: – translate 后端翻译（使用） 这里通过对菜单的翻译来带大家了解翻译模块 Step1 新增翻译记录 切换应用到translate模块，点击新增翻译。 选择新增翻译生效模块 选择翻译的模型为：菜单模型 源语言选择中文，目标选择English 添加翻译项目： 源术语为：商店 翻译值为：shop 状态为：激活 Step2 查看效果 应用切换到Demo模块，在右上角切换语言至英语 后端翻译（自定义模型的翻译） 在前面菜单的翻译中，似乎我们什么都没做就可以正常通过翻译模块完成多语言的切换了。是不是真如我们想象的一样，当然不是。是因为Menu模型的displayName字段加上@Field(translate = true)注解。 Step1 为PetType模型的name字段增加翻译注解 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; import pro.shushi.pamirs.meta.base.IdModel; @Model.MultiTable(typeField = "kind") @Model.model(PetType.MODEL_MODEL) @Model(displayName="品种",labelFields = {"name"}) public class PetType extends IdModel { public static final String MODEL_MODEL="demo.PetType"; @Field(displayName = "品种名" , translate = true) private String name; @Field(displayName = "宠物分类") private String kind; } Step2 重启应用查看效果 切换应用到translate模块，点击新增翻译 切换应用到Demo模块，切换中英文，查看效果 前端翻译 还记得我们前端第一个自定义动作吗？会弹出“oinone第一个自定义Action，啥也没干”，我们要对它进行翻译。 Step1 修改前端DoNothingActionWidget.ts import translateValueByKey 提示语用translateValueByKey加上翻译 const confirmRs = executeConfirm(translateValueByKey(\’oinone第一个自定义Action，啥也没干\’)||\’oinone第一个自定义Action，啥也没干\’); 前端更多翻译工具请见前端高级特性-框架之翻译工具 import { Action, ActionContextType, ActionWidget, executeConfirm, IClientAction, SPI, ViewType, Widget, translateValueByKey } from '@kunlun/dependencies'; @SPI.ClassFactory(ActionWidget.Token({ name: 'demo.doNothing' })) export class DoNothingActionWidget extends ActionWidget { @Widget.Method() public async clickAction() { const confirmRs = executeConfirm(translateValueByKey('oinone第一个自定义Action，啥也没干')||'oinone第一个自定义Action，啥也没干'); } } //定义动作元数据 Action.registerAction('*', { displayName: '啥也没干', name: 'demo.doNothing', id: 'demo.doNothing', contextType: ActionContextType.ContextFree, bindingType: [ViewType.Table] } as IClientAction); Step2 新增翻译记录 前端翻译的翻译记录对应的模型可以随意找一个放。但要注意几点： 不要找有字读配置translate = true的模型，因为会影响后端翻译性能。 最好统一到一个模型中，便于后续管理。这里大家可以自定义一个无有业务访问且本身无需要翻译的模型来挂载，避免性能损失 Step3 刷新远程资源生成前端语言文件 Step4 新增或修改.env 前端在项目根目录下新增或修改.env，可以参考.env.example文件。通过.env文件为前端配置oss文件路径，针对I18N_OSS_URL配置项。真实前端访问翻译语言文件的路径规则为：http://bucket.downloadUrl/mainDir/租户/translate/模块/语言文件。 yaml文件中oss配置的文件路径：http://pamirs.oss-cn-hangzhou.aliyuncs.com/upload/demo/ 租户/translate/模块/语言文件 前端会自动根据上下文组织 # 后端api配置 # API_BASE_URL=http://127.0.0.1:8090 # 下面是国际化语言的cdn配置，默认用当前请求链接下的路径: /pamirs/translate/${module}/i18n_${lang}.js I18N_OSS_URL=http://pamirs.oss-cn-hangzhou.aliyuncs.com/upload/demo Step5 重启前端应用看效果 对语言进行中英文切换，进入宠狗达人页面，点击【第一个自定义Action】，查看前端翻译效果
我们默认视图已经基本可以用了，但实际业务中还是会有一些不大不小的自定义需求，写自定义视图又太麻烦，今天我们来学习一种更加轻量的模式即：后端研发可以通过注解来配置视觉交互。该系列注解以Ux开头，例如@UxHomepage、@UxMenu、@UxAction、@UxView、@UxWidget等等。 视图XML的配置优先级大于在代码上的注解，也就是代码上的注解影响的是默认展示逻辑。 一、Ux家族图谱 我们先简单通过家族图谱做个简单了解，脑海里有一个影响当有需要的时候知道能不能做，深入了解还需要大家多多动手去尝试 图3-5-4-1 Ux家族图谱 二、默认视图后端配置举例 在下面的代码片段中UxTable、UxForm、UxDetail、UxTableSearch都有涉及，几个特殊点做些解释其他的留大家自行测试 Group分组的配置逻辑：为了不让一个分组内的字段不断的写Group，所以采取了第一个字段写了Group，到下一个出现的group之间的字段都自动归为一个Group 搜素整体不展示可以用“@UxTable(enableSearch = false)”配置在模型的类上。 字段搜索用“UxTableSearch”配置在模型的字段上，其特殊逻辑是只要你配了一个字段，系统就不自动补充了，例子中表格页的搜索栏只会留下店铺名称和店铺编码 ……其他代码 //@UxTable(enableSearch = false)，整体不支持搜索 public class PetShop extends AbstractDemoIdModel { public static final String MODEL_MODEL="demo.PetShop"; @Field(displayName = "店铺编码") @UxForm.FieldWidget(@UxWidget(group = "Form基础数据"))//Form分组 @UxTableSearch.FieldWidget(@UxWidget())//支持搜索 private String code; @Field(displayName = "店铺编码2") @Field.Sequence(sequence = "DATE_ORDERLY_SEQ",prefix = "C",size=6,step=1,initial = 10000,format = "yyyyMMdd") private String codeTwo; @UxTableSearch.FieldWidget(@UxWidget())//支持搜索 @UxTable.FieldWidget(@UxWidget(invisible = "true"))//表格中不展示支持搜索 @Field(displayName = "店铺名称",required = true,immutable=true) private String shopName; @Field(displayName = "一年内新店") @UxForm.FieldWidget(@UxWidget(widget = "Switch",group = "Form基础数据"))//Switch,Checkbox可以切换着看，字段可选widget参考【字段的配置】一文 private Boolean oneYear; @Field(displayName = "开店时间",required = true) @UxDetail.FieldWidget(@UxWidget(invisible = "true"))//详情不展示 private Time openTime; @Field(displayName = "闭店时间",required = true) @UxDetail.FieldWidget(@UxWidget(invisible = "true"))//详情不展示 private Time closeTime; …… 其他代码 } 图3-5-4-2 默认视图后端配置举例
如果说低代码开发框架输出技术标准，CDM则是结合oinone技术特性和软件工程设计，让输出数据标准变成可能。 一、背景介绍 无法照搬的最佳实践 要了解引入CDM的初衷，得从互联网架构的演进开始，了解其过程，就知道为什么说Oinone的CDM是中台架构的最佳技术实践的核心！我们在2.2【互联架构做为最佳实践为何失效】一文中介绍过互联网技术发展的四个阶段，特别平台化到中台化的阶段，目的是在一套规范下让听的见炮火声音的团队自行决定业务系统发展，适用多业务线（或多场景应用）独立发展。 互联网架构在演进过程中碰到的问题跟企业数字化转型过程中碰到的问题是非常类似： 随着企业业务在线化后对系统性能、稳定都提出了更高的要求，而且大部分企业的内部很多系统相互割裂导致，导致很多重复建设，所以我们需要服务化、平台化。 同时没有一个供应商能解决企业所有商业场景问题，又需要多个供应商共同参与，所以把供应商类类比成各个业务线，在一套规范下让供应商自行决定业务系统发展 既然跟阿里当初在架构演进过程中碰到的问题非常类似，那么是不是照搬阿里中台架构方案到企业就好了？当然不是，因为历史原因阿里的中台架构是采用的平台共建模式：“让业务线研发以平台设计好的规范进来共同开发”，其本质还是平台主导模式，它是有非常大的历史包袱。我们想象各个供应商的共建一个交易平台或商品平台，那是多么荒唐的事情，平台化已经足够的复杂了，还让不同背景、不同企业的研发一起共建，最后往往导致企业架构负载过重，这时对企业来说便不再是赋能而是“内耗”。 那么如果没有历史包袱，我们重新设计，站在上帝视角去看有没有更好的方式呢？当然有 借鉴微软的CDM 这里我们借鉴微软的CDM理念，CDM这个概念最早是2016年微软宣布“以Dynamics 365的形式改造其CRM和ERP”战略时提出的。微软给它的定义是“用于存储和管理业务实体的业务数据库，而且是开箱即用的”。CDM不仅仅提供标准实体，它还允许用户建立个性化的实体，用户可以扩展标准实体也可以增加和标准实体相关的新实体。 CDM可能并不性感，但绝对是非常必要的。它成为了微软的很多产品的基础，是构建了无数业务领域的原型。同时微软也期望它能成为快速实现数据交换和迁移的标准，这个有点像菜鸟网络推出的奇门，让所有TMS、OMS、WMS都基于一套数据接口API进行互通，一套标准是为了解决一个行业问题，而不是具体某一个企业一个集团的问题。 我们发现CDM的理念跟我们想要的“企业级的数据标准”是非常吻合的。但是我们也不能照搬照抄，虽然微软的CDM很好的解决了数据割裂问题，但就模型来说就够大家喝一壶了，模型库非常庞大而且复杂，学习成本巨高。 数字化时代软件会产生新的技术流派 我们知道传统软件的设计理念：侧重在模型对业务支撑全面性上。优点体现为配置丰富，缺点模型设计过于复杂，刚开始有前瞻性，但在理解、维护都非常困难，随着业务发展系统原先的设计逐渐腐化，异常笨重。 而Oinone的CDM设计理念：侧重在简单、灵活、统一上，体现为在上层应用开发时，每一业务领域保持独立，模型简单易懂，并结合Oinone的低代码开发机制进行快速开发，灵活应对业务变化。 所以我更想说Oinone的CDM是微软CDM的在原有基础上，与互联网架构结合，利用Oinone低代码开发平台特性形成新的工程化建议。Oinone-CDM不以把模型抽象到极致，支撑“所有业务可能性”为目标，而是抽象80%通用的设计，保持模型简单可复用，来解决数据割裂问题，并保持业务线独立自主性，快速创新的能力。 图5-1-1 Oinone-CDM要解决的问题 二、Oinone的CDM本质是创新的工程化建议 引入CDM以后系统工程结构会有什么变化，跟大家认知的互联网架构有什么区别。 原本上层的业务线系统，需要调用各个业务平台提供的功能，增加CDM以后也就是我们右的图，每个业务线就像一个独立右边。看上去复杂了，其实对业务线来说更加简单了。 互联网整体平台化带来的问题： 业务线每次业务调整都需要给各个平台提需求 业务平台研发需要了解所有业务线的知识再做设计，对研发要求非常高 各个业务域的不同需求相互影响包括系统稳定性、研发对需求响应的及时性 结合oinone特性提出的新工程建议： 一些通用性模块继续以平台化的方式存在，能力完全复用。 业务线自建业务平台，保持业务线的独立性和敏捷性 业务线以CDM为原型，保证核心数据不割裂，形成一致的数据规范 图5-1-2 引入CDM概念后的工程结构对比 三、CDM思路示意图 该示例中OinoneCDM的商品域不仅仅提供标准实体，保证各个业务系统的对商品的通用需求、简单易懂，在我们星空系列业务产品中如全渠道运营、B2B交易等系统以此为基础建立属于自身个性化的实体，可以扩展标准实体也可以增加和标准实体相关的新实体。 带来的好处： 通过多种继承方式，继承后的模型可扩展模型本身、模型行为等，从而解决业务独立性问题。 通过CDM层统一数据模型，从而解决多应用数据割裂问题 图5-1-3 Oinone-CDM思路示意图
