模块(module):是按业务领域划分和管理的最小单元，是一组功能、界面的集合。
带大家快速认识下如何构建一个oinone的模块并启动它。我会从以下几个维度去介绍模块的构建与启动方式、模块详解。让大家直观且全方位地了解oinone的模块所包含的内容
构建第一个Module
启动前端工程
应用中心
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9227.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
1. 创建用户 进入用户中心应用，在用户列表中点击创建。 填写表单中的必填信息。 若未设置昵称，则右上角头像右侧展示名称。若设置了昵称，则右上角头像右侧展示昵称。 是否激活账号选择是，选择否时用户登录会显示“未找到首页”。 角色分组中，选择创建的用户的角色，默认选择了超级管理员（包含所有权限）。 点击确定，用户创建完成。 用户登录时可用登录账号/邮箱/手机号登录。 2. 用户相关操作 表格页中包含常规的搜索、批量删除功能。 冻结：当将“是否有效”状态为“是”时展示，将用户“是否有效”修改为“否”。 解冻：当将“是否有效”状态为“否”时展示，将用户“是否有效”修改为“是”。 修改：进入用户信息修改页面，“编码、登录账号、注册时间”只读。 重置密码：点击后在弹窗“账号确认”中输入账号，点击重置密码后，展示新密码。
1. 功能说明 页面设计时界面设计器中「页面」模块的设计入口，在这个界面，进行页面的设置、搭建、设计、排版。 主要分为顶部操作栏、左侧工具栏、中部设计画布区、右侧属性面板。 2. 操作栏 进入页面设计，顶部显示了页面的标题，以及返回、发布等操作。 2.1 发布 页面设计完成后，点击「发布」运行页面生效。若不点击发布，页面也有自动保存的功能，但在发布前，自动保存也等同于草稿，不会正式生效。 发布时如果有属性不符合校验规则（必填的属性未填、输入的内容校验不通过），会发布失败，相应的字段会特殊标记，需要查看并修改属性。 2.2 显示/隐藏母版 进入页面设计时默认不展示母版，可以手动操作显示母版 3. 工具栏 左侧的工具栏中包括组件库、页面设置等模块。 3.1 组件库 组件库中包含组件和模型，组件是当前设计器支持的所有组件，模型是页面所在模型下的所有字段和动作。 3.1.1 组件 组件中展示了系统支持的所有组件。包含 1）布局类组件，如分组、选项卡等，使用布局组件可以将页面进字段分类、分页； 2）字段类组件，如单行文本、整数、日期等等，使用字段类组件时都会在模型下对应创建一个字段； 3）动作类组件，如跳转动作、提交动作、链接动作等。 3.1.2 模型 组件库顶部，由组件可切换为模型：模型选项下，会展示当前模型的所有字段，以及系统默认动作。可以直接拖拽字段至设计画布中，会应用形成某个组件，可对组件进行多样的属性设置，优化交互。 3.1.2 组件和模型有什么区别 1展示内容维度不同 组件中展示的内容是组件信息，如分组、选项卡、单行文本、文件上传等；模型中展示的是模型下已有的所有字段。 2使用功能不同 组件中的组件使用前需要在模型中创建一个字段，当然，创建好的字段也会存在于模型中；模型中的字段可直接使用，并且使用时会在设计画布中对应生成个默认组件。 3使用场景不同 如果模型中已经存在目标字段，应直接选择从模型中拖拽字段；如果模型中没有需要的字段，可以在页面中增加一个组件，实际上也是在新增一个字段。 3.2 页面设置 页面设置中可以修改当前页面的标题、分组、页面描述，同时也是给页面上传缩略图的唯一入口。 4. 设计画布 将组件或字段拖拽至设计画布区，会生成样式。点击组件，右侧可对其进行设置，大部分属性可实时在画布中展示效果。 5. 属性面板 右侧属性面板抽屉中可以设置属性或查看字段信息，通过不同的属性配置化实现组件的多样化。 5.1 属性 属性中包括基本信息（如标题、占位提示、描述说明等）、校验信息（如是否必填、长度校验等）、交互信息（如排序方式、是否展示计数器等） 5.2 字段 首次从组件中拖拽，会先展示字段信息，并且是需要先创建一个字段，字段创建成功后，再次切换字段选项，只读展示当前组件所对应的字段基本信息。同理，如果是直接从字段中拖拽，字段选项中，只读展示当前字段基本信息。
一、基础介绍 随着企业的业务不断进行数字化改造、业务越来越在线化，给企业财务工作带来几个明显的变化和挑战： 变化： 业务在线后，不同类收费、预售、授信模式的创新层出不穷，需要财务不仅只从事单一传统的会计核算工作，还需要积极地参与到业务中去。 从事后算账事后报账，变成财务业务一体化信息的实时处理 挑战： 业务系统与财务系统明显割裂，业务部门与财务部门各自采用一套软件处理其数据，不能及时沟通信息和协同更正信息。 财务系统往往都是单体的传统架构，凭证处理能力无法适应今天企业的不断爆棚的业务发展。 财务的严谨性与业务的灵活性中间有巨大的鸿沟，导致业务要做一种创新的模式，财务可能是最大阻碍。 不论是传统软件公司喜欢说的业财一体化还是互联网平台公司喜欢说的结算平台，都是为了解决以上变化和挑战的。业财一体化主要是从财务部门角度出发进行，在业务支撑上化被动为主动。结算中心往往是结合财务部门和业务运营部门的需求。如果拿我们下面介绍的，计费、账务、会计三个领域来说，业财一体化项目往往只包括账务和会计，结算中心往往包括：计费、账务、会计。或者说业财一体化弱化了计费，没有纳入企业统一管理，把如何计价给到了业务系统自行决定或者简单处理只要产生应收应付单据（计费详单）就好了。 结算域的是一个相对比较专业的领域，没有一定背景知识甚至连一些专业名词都很难理解，更不用说模型设计了，这里我尽快地简单去描述定位而不是描述细节。而且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 结算基础流程
因为默认视图很难满足客户的个性化需求，所以日常开发中view的配置是避免不了的。本系列篇是比较全面地介绍View配置的各个方面涉及：视图、字段、动作、布局等
我们的Oinone平台采用模型驱动的方式，并符合面向对象设计原则，每个需求都可以是一个独立模块，可以独立安装、升级和卸载。这让系统真正像乐高积木一样搭建，具有高度的灵活性和可维护性。 与大部分低代码或无代码平台不同的是，它们的应用市场上的应用往往是模板式的，也就是说，这是一个拷贝，个性化只能在应用上直接修改，而且一旦修改就不能升级。这对于软件公司和客户来说都非常痛苦。客户无法享受到软件公司产品的升级功能，而软件公司在服务大量客户时，也会面临不同版本的维护问题，成本也非常高。而我们的Oinone平台完全避免了这些问题，让客户和软件公司都可以从中受益（如下图2-9、2-10所示）。 图2-9软件公司与客户项目的关系-让标准与个性化共存 图2-10 软件公司与客户项目的关系-让升级无忧 实现原理 在满足客户个性化定制需求时，传统的方法通常是直接修改标准产品源码，但这样做会带来一个问题：标准产品无法持续升级。相反，无论是在OP模式还是SaaS模式下，Oinone都采用全新的模块为客户进行个性化开发，保持标准产品和个性化模块的独立维护和升级。这是因为在元数据设计时，Oinone采用了面向对象的设计原则，实现了元数据设计与面向对象设计思想的完美融合。 面向对象设计的核心特征包括封装、继承、多态，而Oinone的元数据设计完全融入了这些思想。下面是几个例子，说明Oinone的元数据设计如何体现面向对象设计的核心特征，并带来了什么好处： 继承：在继承原有模型的字段、逻辑、展示的情况下，增加一段代码来扩展模型的字段、逻辑、展示。 多态：在继承原有模型的字段、逻辑、展示的情况下，增加一段代码来覆盖模型的原有字段、逻辑、展示。 封装：外部无需关心模型内部如何实现，只需按照不同场景调用模型对应开放级别的字段、逻辑、展示。 这些特征和优势使得Oinone在满足客户个性化需求时更加灵活和可持续，同时使得标准产品的维护和升级变得更加容易和高效。 在Java语言设计中，万物皆对象，一切都以对象为基础。而Oinone的元数据设计则是以模型为出发点，作为数据和行为的承载体。如下图2-11清晰地描述了Java面向对象编程中封装、继承、多态在Oinone元数据中的对应关系。Oinone元数据描述了B对象继承A对象并拥有其所有属性和方法，并覆盖了A对象的属性1和方法1，同时新增了属性3和方法3。 此外，Oinone的面向对象特性是用元数据来描述的。一方面，我们基于Java编码规范收集相关元数据，以保持不改变Java编程习惯。另一方面，方法和对象的挂载是松耦合的，只要按照元数据规范进行挂载，就能轻松地将其附加到模型上。在不改变原有A对象的情况下，我们可以直接增加方法和属性（如下图2-12所示）。 图2-11 java面向对象在Oinone元数据中对应 图2-12 java对象的修改 VS Oinone元数据模型的修改 Oinone函数不仅支持面向对象的继承和多态特性，还提供了面向切面的拦截器和SPI机制的扩展点，以应对方法逻辑的覆盖和扩展，以及系统层面的逻辑扩展（如下图2-13所示）。这些扩展功能可以独立地在模块中维护。 其中，拦截器可以在不侵入函数逻辑的情况下，根据优先级为满足条件的函数添加执行前和执行后的逻辑。 扩展点是一种类似于SPI机制的逻辑扩展机制，用于扩展函数的逻辑。通过这一机制，可以对函数逻辑进行灵活的扩展，以满足不同的业务需求。 图2-13 Oinone函数拦截与扩展机制 不管是对象、属性还是方法，都可以以独立的模块方式来扩展，这就使得每一个需求都可以成为一个独立的模块，方便我们在研发标准产品时进行模块化的划分，同时也让我们在以低代码模式为客户进行二次开发时，能够更好地支持“标准产品迭代与个性化保持独立”的需求。在2.4.3【oinone独特性之低无一体】一文中，我们也提到了这个特性，但那是在低无一体的情况下，通过元数据融合来实现的。让我们看看基于低代码开发模式下，典型的Oinone二次开发工程结构（如下图2-14所示），就可以更好地理解这个特性啦！ 图2-14 Oinone典型的二开工程结构
