5.4 基础支撑之商业关系域

相关推荐

• Oinone 7天入门到精通

  4.4 Oinone的分布式体验进阶

  在分布式开发中，每个人基本只负责自己相关的模块开发。所以每个研发就都需要一个环境，比如一般公司会有（N个）项目环境、1个日常环境、1个预发环境、1个线上环境。在整项目环境的时候就特别麻烦，oinone的好处是在于每个研发可以通过boot工程把需要涉及的模块都启动在一个jvm中进行开发，并不依赖任何环境，在项目开发中，特别方便。但当公司系统膨胀到一定规模，大到很多人都不知道有哪些模块，或者公司出于安全策略考虑，或者因为启动速度的原因（毕竟模块多了启动的速度也会降下来）。本文就给大家介绍oinone与经典分布式组织模式的兼容性 一、模块启动的最小集 我们来改造SecondModule模块，让该模块的用户权限相关都远程走DemoModule Step1 修改SecondModule的启动工程application-dev.yml文件 除了base、second_core两个模块保留，其他模块都去除了。 pamirs: boot: init: true sync: true modules: – base – second_core 图4-4-1 SecondModule的application-dev.yml仅配置两个模块 Step2 去除boot工程的依赖 去除SecondModule启动工程的pom依赖 <!– <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-resource-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-auth-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-message-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-international</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-business-core</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-apps-core</artifactId> </dependency> –> 图4-4-2 去除boot工程多余的依赖 Step3 重启SecondModule 这【远程模型】和【远程代理】均能访问正常 图4-4-3 远程模型和远程代理菜单均能访问正常 Step4 SecondModule增加对模块依赖 我们让SecondModule增加用户和权限模块的依赖，期待效果是：SecondModule会对用户和权限的访问都会走Dome应用，因为Demo模块的启动工程中包含了user、auth模块。 修改pamirs-second-api的pom文件增加对user和auth的api包依赖 <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-user-api</artifactId> </dependency> <dependency> <groupId>pro.shushi.pamirs.core</groupId> <artifactId>pamirs-auth-api</artifactId> </dependency> 图4-4-4 修改pamirs-second-api的pom文件 修改SecondModule类，增加依赖定义 @Module( dependencies = {ModuleConstants.MODULE_BASE, AuthModule.MODULE_MODULE, UserModule.MODULE_MODULE} ) 图4-4-5 配置SecondModule的依赖 Step5 修改RemoteTestModel模型 为RemoteTestModel模型增加user字段 @Field.many2one @Field(displayName = "用户") private PamirsUser user; 图4-4-6 为RemoteTestModel模型增加user字段 Step6 重启系统看效果 mvn install pamirs-second工程，因为需要让pamirs-demo工程能依赖到最新的pamirs-second-api包 重启pamirs-second和pamirs-demo 两个页面都正常 图4-4-7 示例效果一 图4-4-8 示例效果二 二、PmetaOnline的NEVER指令（开发时环境共享） 我们在4.1.2【模块之启动指令】一文中介绍过 “-PmetaOnline指令”，该参数用于设置元数据在线的方式，如果不使用该参数，则profile属性的默认值请参考服务启动可选项。-PmetaOnline参数可选项为： NEVER – 不持久化元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为false MODULE – 只注册模块信息，会将pamirs.boot.options中的updateModule属性设置为true，reloadMeta和updateMeta属性设置为false ALL – 注册持久化所有元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为true oinone的默认模式下元数据都是注册持久化到DB的，但当我们在分布式场景下新开发模块或者对已有模块进行本地化开发时，做为开发阶段我们肯定是希望复用原有环境，但不对原有环境照成影响。那么-PmetaOnline就很有意义。让我们还没有经过开发自测的代码产生的元数据仅限于开发本地环境，而不是直接影响整个大的项目环境 PmetaOnline指令设置为NEVER（举例） Step1 为DemoCore新增一个DevModel模型 package pro.shushi.pamirs.demo.api.model; import pro.shushi.pamirs.meta.annotation.Field; import pro.shushi.pamirs.meta.annotation.Model; @Model.model(DevModel.MODEL_MODEL) @Model(displayName = "开发阶段模型",summary="开发阶段模型，当PmetaOnline指令设置为NEVER时，本地正常启动但元数据不落库",labelFields={"name"}) public class DevModel extends AbstractDemoCodeModel{ public static final String MODEL_MODEL="demo.DevModel"; @Field(displayName = "名称") private String name; } 图4-4-9 为DemoCore新增一个DevModel模型 Step2 为DevModel模型配置菜单 @UxMenu("开发模型")@UxRoute(DevModel.MODEL_MODEL) class DevModelProxyMenu{} 图4-4-10 为DevModel模型配置菜单 Step3 启动Demo应用时指定-PmetaOnline 图4-4-11 启动Demo应用时指定-PmetaOnline Step4 重启系统看效果 查看元数据 图4-4-12 DB查看元数据变化 菜单与页面能正常操作 图4-4-13 开发模型菜单可正常操作 图4-4-14 开发模型详情页面可正常操作 Step5 Never模式需注意的事项 业务库需设定为本地开发库，这样才不会影响公共环境，因为对库表结构的修改还是会正常进行的 如果不小心影响了公共环境，需要对公共环境进行重启恢复 系统新产生的元数据（如：例子中的【开发模式】菜单）不受权限管控 三、分布式开发约定 设计约定 跨模块的存储模型间继承，在部署时需要跟依赖模块配置相同数据源。这个涉及模块规划问题，比如业务上的user扩展模块，需要跟user模块一起部署。…

  史, 昂

  2024年5月23日

  1.7K000
• Oinone 7天入门到精通

  3.2.3 应用中心

  在App Finder 中点击应用中心可以进入oinone的应用中心，可以看到oinone平台所有应用列表、应用大屏、以及技术可视化。 一、应用列表 标准版本不支持在线安装，只能通过boot工程的yml文件来配置安装模块。在 www.oinone.top 官方SaaS平台客户可以在线管理应用生命周期如：安装、升级、卸载。同时针对已安装应用可以进行无代码设计（前提安装了设计器），针对应用类的模块则可进行收藏，收藏后会在App Finder中的我收藏的应用中出现。在应用列表中可以看到我们已经安装的应用以及模块，我们oinoneDemo工程也在其中。 图3-2-35 Oinone的应用列表 图3-2-36 应用收藏后会在App Finder的【我收藏的应用】中出现 二、应用大屏 但我们的测试应用没有设置应用类目，则无法在应用大屏中呈现。 图3-2-37 未设置应用类目则无法在应用大屏中呈现 三、技术可视化 在技术可视化页面，出展示已经安装模块的元数据，并进行分类呈现 图3-2-38 云数据分类呈现

  史, 昂

  2024年5月23日

  2.7K000
• Oinone 7天入门到精通

  数据类

  1.数据类 1.1 新增数据 新增数据节点可以为任意模型通过表达式新增数据，包含两种模式，「节点执行完即增加业务数据」功能下新增的数据也可以同步触发流程，相反「节点执行完不增加业务数据」则不会触发新增业务数据关联的流程，数据仅可用于后续流程使用。 流程增加的数据在节点执行时就生效。 1.2 更新数据 更新数据节点可以为任意模型通过表达式更新数据。 1.3 获取数据 当流程需要调用触发模型之外的模型中的数据时就需要使用获取数据的功能。 需要选择获取单条/多条数据，选择一个获取数据的模型，可以设置一些筛选项减少不必要的数据。最后需要设置未获取到数据时的执行方式。 继续执行：跳过本次数据获取，继续执行流程。 向模型中新增数据后继续执行：新增数据来供后续节点使用，新增数据同时存入数据库中。 终止流程：终止流程将结束该流程，不管之后是否还有流程节点。 1.4 删除数据 删除数据节点可以将流程节点上面的模型数据从数据库中删除。 1.5 更新流程参数 可以将「流程配置」中的「流程参数」进行修改，仅有变更过的流程参数才能其他节点选中。 1.6 引用逻辑 可以在流程中使用模块自带的逻辑或使用低代码设计的逻辑。

  史, 昂

  2024年5月23日

  2.1K000
• Oinone 7天入门到精通

  5.1 CDM的背景介绍

  如果说低代码开发框架输出技术标准，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思路示意图

  史, 昂

  2024年5月23日

  1.3K000

• 3.4.3 函数的相关特性

  本小章会从oinone的函数拥有三方面特性，展开介绍 面向对象，继承与多态 面向切面编程，拦截器 SPI机制，扩展点

  史, 昂

  Oinone 7天入门到精通 2024年5月23日

  1.4K000