5.2 CDM之工程模式

两种工程模式介绍

oinone推荐的两种工程模式都保留互联网特性,如跟业务无关的基础平台还是采用平台化思路建设。二种侧重点差异如下

  1. 第一种:比较适合企业采用多供应商联合开发场景,先以业务区分,各个业务线有独立的领域平台,最大限度保持不同业务线的独立性,有利于各个业务线独立发展(目前oinone上层星空系列产品采用这种工程模式,因为我们期望的时候帮助企业构建软件生态,必然要考虑不同供应商联合开发场景)

  2. 第二种:比较接近传统互联网架构,先按平台领域区分,如商品领域:商品平台做总工程,但里面按业务区分模块分子工程来保持业务相互独立,相对于第一种把领域的代码放一起,带来好处强化大家思考模型通用性。但不适用于跨公司主体间配合。

5.2 CDM之工程模式

图5-2-1 Oinone-CDM的两种工程模式

注意事项:

  1. oinone兼容传统互联网架构

  2. 不管哪种模式,都需要解决CDM的维护问题

CDM维护的常见问题:

Q:CDM层缺少模型怎么办?

A:CDM层模型是逐步完善和丰富的。如果是特定业务自己需要的模型,这类模型无通用性。则加到自己的工程中;如果是通用的,则架构组确定是否需要纳入到CDM。

Q:CDM层已有的模型缺少字段怎么办?

A:CDM层模型的字段也是逐步完善和丰富的,通用的字段在架构组确定后也会被吸收进来

Q:CDM层不同业务线相互影响怎么办?

A:扩展字段最好带上自有前缀标志,如果觉得通用则提交架构组走模型缺少字段加入

Q:CDM层某模型新增加了的字段,但原先业务线已经加了相同含义字段

A:业务线可以把自己的字段related到CDM增加的新字段,并做数据迁移

Oinone社区 作者:史, 昂原创文章,如若转载,请注明出处:https://doc.oinone.top/oio4/9317.html

访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验

Like (0)
史, 昂's avatar史, 昂数式管理员
Previous 2024年5月23日 am8:21
Next 2024年5月23日 am8:23

相关推荐

  • 3.5.6.2 视图的配置

    ,视图的大致配置在3.5.2.2【构建View的Template】一文中已经介绍过,这里主要介绍视图层的基本属性配置,这些配置会透传给视图内的组件Widget,组件会根据配置内容做出不同的呈现样式 视图的配置 Table的配置 配置项 可选值 默认值 作用 activeCount number 5 表格上方动作区默认展示操作的数量,超过个数的操作将被折叠收起 inlineActiveCount number 3 表格最右侧操作列默认展示操作的数量,超过个数的操作将被折叠收起 defaultPageSize number 30 表格默认分页条数 表3-5-6-9 Table的配置 Form/Detail的配置 配置项 可选值 默认值 作用 direction horizontal/vertical(大小写不明感) vertical 表单标题排列方式 表3-5-6-10 Form/Detail的配置 Table的配置项举例 Step1 修改宠物达人的表格视图 我们在宠物达人的自定义表格视图的Template文件中增加三个属性配置activeCount="1" 、inlineActiveCount="1"、 defaultPageSize="1" <view name=tableView model=demo.PetTalent cols=1 activeCount=1 inlineActiveCount=1 defaultPageSize=1 type=TABLE enableSequence=true > </view> 图3-5-6-15 在宠物达人的自定义表格视图的Template文件中增加三个属性配置 Step2 重启看效果 图3-5-6-16 示例效果 Form的配置举例 Step1 修改宠物达人的表单视图 我们在宠物达人的自定义表格视图的Template文件中增加一个属性配置direction = horizontal 。 另:宠物达人在之前的教程中增加了一些字段,大家利用默认视图把新增字段也展示出来。还是通过数据库查看默认页面定义,找到base_view表,过滤条件设置为model =\’demo.PetTalent\’ and name =\’formView\’,查看template字段,把里面涉及新增字段复制到pet_talent_form.xml文件中。 <view name=formView1 model=demo.PetTalent cols=2 type=FORM priority=1 direction = horizontal> </view> 图3-5-6-17 增加一个属性配置direction = "horizontal" Step2 重启看效果 图3-5-6-18 示例效果

    2024年5月23日
    1.8K00
  • 登录日志

    1. 登录日志 登录日志:记录企业成员/用户登录平台的历史明细,包括登录时间、位置、IP、登录设备、登录平台等信息,登录平台包括:PC Web、小程序、H5、APP。登录日志不需要通过审计规则订阅,平台会记录每位用户的登录日志。 操作支持导出、查看详情。

    2024年6月20日
    1.6K00
  • 5.5 基础支撑之结算域

    一、基础介绍 随着企业的业务不断进行数字化改造、业务越来越在线化,给企业财务工作带来几个明显的变化和挑战: 变化: 业务在线后,不同类收费、预售、授信模式的创新层出不穷,需要财务不仅只从事单一传统的会计核算工作,还需要积极地参与到业务中去。 从事后算账事后报账,变成财务业务一体化信息的实时处理 挑战: 业务系统与财务系统明显割裂,业务部门与财务部门各自采用一套软件处理其数据,不能及时沟通信息和协同更正信息。 财务系统往往都是单体的传统架构,凭证处理能力无法适应今天企业的不断爆棚的业务发展。 财务的严谨性与业务的灵活性中间有巨大的鸿沟,导致业务要做一种创新的模式,财务可能是最大阻碍。 不论是传统软件公司喜欢说的业财一体化还是互联网平台公司喜欢说的结算平台,都是为了解决以上变化和挑战的。业财一体化主要是从财务部门角度出发进行,在业务支撑上化被动为主动。结算中心往往是结合财务部门和业务运营部门的需求。如果拿我们下面介绍的,计费、账务、会计三个领域来说,业财一体化项目往往只包括账务和会计,结算中心往往包括:计费、账务、会计。或者说业财一体化弱化了计费,没有纳入企业统一管理,把如何计价给到了业务系统自行决定或者简单处理只要产生应收应付单据(计费详单)就好了。 结算域的是一个相对比较专业的领域,没有一定背景知识甚至连一些专业名词都很难理解,更不用说模型设计了,这里我尽快地简单去描述定位而不是描述细节。而且2.1.9版本的结算领域相对还是没有那么完善,这里介绍的是下个版本的内容,所以大家看当前版本的时候会有一些对不上。 二、子领域职责 图5-5-1 子领域职责 计费 计费的价值 随着企业多业务发展以及融合计费需求,我们需要引入计费模型,对灵活计价模式进行支持,快速支撑未来可能的计费方式等 计费的核心设计理念 所有的计算器都继承自虚函数计算器y=f(x) 平滑兼容-默认斜率计算器y=a+bxY – 求值结果(用下标描述结果是什么)A – 偏移量(计算固定值)B – 斜率(费率值)X – 变量(数量)任何计算都是通过一组斜率组合出来的 利用区间限定定义各种斜率组合出各种算法交易额0-100w:y=0.03x >100w:y=0.02x;时间0:00-6:00:y=0.02x 6:00-24:00:y=0.03xX- 变量,数量 图5-5-2 计费的核心设计理念 更灵活多维区间组合,时间维度、计数器维度、其它属性维度计数器区间斜率限定,比如交易额、空间、使用月份数… 计费的核心功能 通过产品定义运营方案 通过订购产品完成商务合同的签订来决定客户计费策略,或者通过系统产品定义通用计费策略 支撑各类产品的模拟计费 以事件驱动,根据事件、产品、订购关系完成产品路由,并实时产生计费详单 根据计费科目与账务科目,打通账务进行核销 账务 账务的价值 以账户账本为中心,提供记账、账户管理,以及账务的实时监控与持续对账。如果计费是对接业务,那么账务的价值是对接财务系统 账务的核心设计理念 不依赖计费,可独立对接,所有业务最终都需要反馈到帐户账本的操作上,并通过账本明细记录所有操作 账务的核心功能 记账:充值、转账、提现,冻结、解冻,差错处理 账务管理:开户、科目维护 账务查询:对账 会计(暂不在计划内) 会计的价值 结算平台的会计模块不是严格意义上的会计系统,它主要是衔接其他的财务系统,做凭证前置处理。在于汇总凭证,产出业务帐,对接到财务总帐系统,缓解财务系统压力。 三、模型介绍 图5-5-3 模型介绍 四、结算基础流程 图5-5-4 结算基础流程

    2024年5月23日
    1.3K00

Leave a Reply

Please Login to Comment