5.6 商业支撑之商品域

相关推荐

• Oinone 7天入门到精通

  特别说明

  教材进度 目前还在编写整改中，特别是目录上带（改）字样的 本版本教材针对4.0，相对3.0增加的特性有： 通用能力部分：比如权限、审计、国际化、系统配置、集成可视化等 新版权限：交互优化，同时支持子管理员 新版审计，支持在线配置审计规则 系统配置，提供多种风格，让伙伴基础风格不在需要自定义主题和组件 新增集成设计器，通过连接器让应用api和数据库集成资产化管理，通过数据流进行接口逻辑编排，并提供统一的开放平台 设计器部分： 加强界面设计器部分对移动端、主题、自定义组件等支持，同时完善对数据管理操作、增加各类常用业务组件，加强对树形与及联的支持，表格视图搜索优化 流程设计器增加：审批员选择自定义逻辑、转交人选择自定义逻辑，支持手工触发、支持数据事务、支持调用模型函数 可视化设计器：增加自定义图表功能、增强下钻能力 模块管理：增加新增、多端配置等支持 内核机制： 性能优化：通过gql层面解决业务研发过程中1+N性能问题，权限性能优化，分布式缓存性能优化，整体性能提升2倍以上 针对多租户应用无状态的支持，低无一体支持本地调试 5.0的核心新特性预告，特性会在开发过程中陆续推出供大家体验，但完整体验时间为2024年6月份 新增打印设计功能 导出的默认交互增强以及导入导出模版设计 默认导入导出在交互时可以指定字段 导入导出模版可图形化设计 多模型AI集成设计器器 自定义组件、自定义图表交互友好性增强 自定义组件，属性面板设计模版化，解决设计组件属性面板的时候不知道有哪些默认属性。 增强组件与动作的结合灵活性 组件增加是否有子组件的通用属性，有子组件的组件具备组件拖拽区 增强UX注解能力，原本只有设计器支持的，后端UX注解也进行对应支持 后端低无一体功能开放（原本该功能只在saas版本上提供），方便咱们做应急和简单应用的时，以无代码为主，低代码为辅的模式。通过低无一体可以通过低代码的方式来解决无代码无法支撑的功能。 工作流增强 增加循环审批节点 增加分支汇集节点增强并行流程能力，比如分支汇集节点可以设置：所有并行节点处理完或只要一条处理完就继续执行。

  史, 昂

  2024年5月23日

  2.3K001
• Oinone 7天入门到精通

  1.5 Oinone与行业对比

  随着企业数字化转型的推进，软件公司获得了许多机会。尽管竞争日趋激烈，但由于需求旺盛，各种模式仍在不断涌现。因此，当前市场上存在各种各样的数字化转型解决方案，围绕企业的各个方面展开。每种解决方案都有其优点和缺点。本文将从定位、技术和产品等方面简单比较，帮助您从不同的视角了解Oinone的差异。 1.4.1 整体视角对比 一、与对标公司Odoo的对比 Odoo Oinone 定位 一站式全业务链管理平台：赋能企业信息化升级 一站式低代码商业支撑平台：赋能企业数字化升级 需求变化 关注单一企业的管理、流程、效率的提升 关注企业价值链的网络竞争，围绕外部协同、运营、数据、商业展开 技术更替 关注稳定、安全、功能丰富度 除了稳定、安全、功能丰富度以外，更强调需求响应速度、用户体验、系统承载极限与弹性扩展、智能化 表1-1 Oinone与对标公司Odoo的对比 二、与国内低代码或无代码公司对比 低代码或无代码公司 Oinone 定位 低代码开发工具：提供各类系统模版，基于模版快速搭建和个性化配置。但系统模版无法再升级 平台型SaaS：提供各类系统产品，产品安装后客户可以根据需求进行个性化调整，同时产品永远在线可升级 场景差异 只能支持企业内部人员使用，以完成部门级边缘系统为主，一般多为没有专业软件厂商支撑和强临时性特性 从内外部协同的商业场景出发，关注企业核心业务场景，适应【企业业务在线化后，所有的业务变化与创新都需要通过系统来触达上下游】的时代背景，以敏捷响应业务的变化与创新为目标 技术代差 单表支撑100万数据已是业内天花板 支撑单模型数据过亿，无单点瓶颈。封装互联网架构并且做到单体与分布式的灵活部署，为不同大小公司提供不同技术支撑 表1-2 Oinone与国内低代码/无代码公司对比 1.4.2 从技术角度对比 我们不会与其他无代码平台进行比较，因为它们不能解决业务复杂性的问题。相反，我们将重点介绍三种不同的低代码平台模式（如下图1-8所示）。 第一种模式是最基础的低代码平台，也被称为代码生成器。它通过预定义应用程序模板和必要的配置生成代码，简化了工程搭建并提供了一些基础逻辑。虽然在信息化时代内部流程标准化方面较为适合，但在数字化时代外部协同业务在线的情况下就不那么合适了。因为这种模式不能减少研发难度和提高效率，也无法体现敏捷迭代快速创新的优势。 第二种模式是经典的低代码平台，以元数据为基础，以模型为驱动。当无法满足需要时，通过特定方式将代码以插件的形式注入平台，作为低代码平台的内置逻辑，供设计器使用。它的优点在于降低了研发门槛，当无法满足需求时才需要编写代码。它可以实现企业内部的复杂流程和复杂逻辑，但其性能和工程管理存在局限性。性能问题使其不适合处理互联网化的在线业务，而工程管理问题则使其不适合处理快速变化的业务。这也是许多研发人员反对低代码的核心原因之一，因为研发人员变成了辅助角色，而软件工程是一门需要技术能力的学科，让没有技术能力的人主导是违反常理的。对于软件产品公司来说，产品需要迭代规划，需要多人协作，需要工程化管理。 第三种模式是oinone提出的基于互联网架构的低代码平台，它采用低无一体的设计。首先，oinone屏蔽了互联网架构带来的复杂性。其次，同样以元数据为基础，以模型为驱动，但是元数据的生成方式有两种：一种是使用无代码设计器（与经典低代码相同），另一种是通过代码来描述元数据。通过使用代码来描述元数据，可以无缝地与代码衔接，并在不改变研发习惯的情况下降低门槛、提高效率，并进行工程化管理。 最后总结来说：低无一体不仅仅是指两种模式的结合，还包括两种模式的融合应用方式。具体来说，这种融合应用方式可以分为两种情况： 当开发核心产品时，主要采用低代码开发，无代码设计器作为辅助。这种方式可以提高开发效率和代码质量，同时保证产品的快速迭代和升级。 当需要满足个性化或非产品支持的需求时，主要采用无代码设计器，低代码作为辅助。这种方式可以快速地满足客户需求，并且避免对产品的核心代码产生影响。 简单来说，低代码模式适用于产品的迭代升级，而无代码设计器则适用于满足个性化和非产品支撑的额外需求。低代码和无代码模式在整个软件生命周期中都有各自的价值，在不同场景下可以相互融合，发挥最大的优势。 图1-8 代码生成器、低代码平台与Oinone的优缺点对比 1.4.3 从产品角度对比 产品上的对比，从客户、场景满足度、再次销售三个方面来做简易的对比 一、Oinone vs 数字化软件服务商 客户 满足度 销售 Oinone 一站式商业智能软件，更高性价比、用户体验客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 满足企业核心业务需求，并联合伙伴一起满足企业所有需求，无需集成提供统一工作台、数据接口、底层协议，无论基于Oinone的开源框架还是增加其他应用都有很好的扩展性 支持OP+SaaS两种模式，收费方式不同：OP按买断方式进行，SaaS按效果付费跟账号数无关新的模块进行二次销售 数字化软件服务商 针对成熟的大型企业需投入巨大资源和成本客户范围：100亿～1000亿、1000亿以上 满足企业部分需求，无法输出技术标准，无法解决多供应商一起开发的问题，只能通过集成实现对接 OP模式进行销售，通过设置权限来进行来实现二次销售或无法进行二次销售 表1-3 Oinone vs 数字化软件服务商 二、Oinone vs 低代码或无代码行业 客户 满足度 销售 Oinone 一站式商业智能软件客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 从外部商业场景出发，强业务场景驱动，符合企业从信息化管理到业务创新的数字化转变的趋势。提供统一工作台、数据接口、底层协议，无论基于oinone的开源框架还是增加其他应用都有很好的扩展性 支持OP+SaaS两种模式，收费方式不同：OP按买断方式进行，SaaS按效果付费跟账号数无关新的模块进行二次销售 低代码或无代码公司 针对小微企业内部信息化管理诉求，以表单流程为主客户范围：5亿以下 满足企业部门级信息化的适应性需求，无法满足企业核心业务管理与业务创新诉求 按应用模块进行收费，新的模块进行二次销售 表1-4 Oinone vs 低代码或无代码行业 三、Oinone vs 国外对标公司Odoo 客户 满足度 销售 Oinone 一站式商业智能软件客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 从外部商业场景出发，强业务场景驱动，符合企业从信息化管理到业务创新的数字化转变的趋势。基线产品覆盖：采购、营销、服务、销售、交易等企业商业领域。主要涉及行业：零售品牌。其他领域或行业靠合作伙伴共建方式进行 支持OP+SaaS两种模式，收费方式不同：OP按买断方式进行，SaaS按效果付费跟账号数无关新的模块进行二次销售 Odoo 一站式企业管理软件客户范围：5000万~5亿、5亿～100亿、标杆：100亿～1000亿、1000亿以上 从企业内部管理需求出发，逐渐拥有互联网相关应用组件，但还是属于强内部管理、弱外部场景。基线产品覆盖：业务财务一体化、人财务、进销存。主要涉及行业：建造业。其他领域或行业靠合作伙伴共建方式进行 支持OP+SaaS两种模式，收费方式相同：按用户数+应用模块进行收费新的模块进行二次销售 表1-5 Oinone vs 国外对标公司Odoo

  史, 昂

  2024年5月23日

  2.4K200

• 李强

  我们常说“在今天所有的不确定性当中，数字化是最大的确定性”，数字化一定会全面改造所有的行业更是确定的。在菜鸟九年的探索中，我们最大的感受是“未来，任何一个物流企业都会是一个技术公司，真正拉开差距的是：技术与实体产业的结合有多深”。菜鸟“简单极致，贴地疾飞”的技术文化也深刻体现了这一点——好的技术要能解决实际问题。数字化并不是简单地上线一个或几个系统，这是一个贴近业务持续迭代的过程，伴随着这个过程，我相信会诞生非常多的创新技术。 在本书中我看到了工程思维在推进技术创新的缩影，把难的问题转化为简单的问题，用成熟实用的技术分而解之。高性能的微服务框架、CDM、元数据、低代码、无代码等，都是当下非常热门的技术课题，Oinone把这一切都有机地结合起来，形成了一种具备先进理念的全新一代软件产品，每一个特性都贴合企业数字化遇到的实际问题。Oinone的产品设计，把“大道至简，软件自造”贯穿始终，用最简单的方式，帮助企业驾驭数字化，相信会给企业带来不一样的体验。 就跟本书提到的“「企业视角由内部管理转向业务在线、生态在线(协同)带来一系列新的诉求」这一大背景下，以及云、端等新技术的发展，对研发人员的需求越来越大，同时要求越来越高，低代码平台是提升研发效率，降低研发成本的核心手段”，低代码已经不是需不需要的问题，而是怎么选的问题。菜鸟网络自身也在推进自有低代码开发平台，我们有幸邀请本书作者陈鹏程来到菜鸟网络进行了分享交流，收获非常大。如您正在选型低代码开发平台，向您推荐这本书，低无一体的Oinone肯定会打动您。 菜鸟网络CTO李强（在宽）

  史, 昂

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

  2.1K000

• 庄卓然

  从2009年加入阿里至今，经历了“三淘”时期、天猫时期、双十一，到最后的all in无线手淘时期，几乎是赶上了淘系发展的所有历史性事件。在这个过程中，每一次业务的变革都催生着技术的变迁，倒逼着我们用技术的方式去解决业务问题：在存储、IO、网络等环节满足不了淘系的业务规模时，开始去IOE，最后演化成了阿里云；当业务的规模大到不能通过简单加机器的方式去做调整、当开发的规模大到所有人在一起开发会互相影响的的时候，我们开始做SOA改造，最后演化成了业务中台；在经历了几届双十一后的巨大挑战后，我们开创了里程碑式的全链路压测；在手淘时代，为了解决动态发版问题，我们植入容器概念，搭建了可动态插拔的三层架构，一年实现了500多次的发版；为了同时满足写一套代码就解决多端开发和高并发的性能问题，我们做了weex，最后还捐给了开源社区…… 每一次的业务需求推动技术进步，而技术的进步永远会超出我们的想象！ 同为技术宅，我在Oinone身上能清晰地感受到技术演进的脉络，企业在数字化时代，需要一个能快速上手、全面设计、灵活适应且低成本的技术工具，时代的变迁推动了Oinone的诞生。Oinone是一种全新的开发方式，在数字化时代，Oinone在提升研发效率上做出的创新性“低无一体”的设计对传统软件代码开发或者无代码开发一定会有巨大冲击，这种冲击会对软件市场格局造成什么样的变化，我拭目以待。 最后，愿我们这些追光人，在时代的洪流中，都能留下一抹印迹，不辜负时代，不辜负自己。 现任阿里巴巴副总裁，飞猪总裁，曾任阿里大文娱CTO兼优酷COO、淘宝CTO 庄卓然（南天）

  史, 昂

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

  2.1K000
• Oinone 7天入门到精通

  3.5.7.6 自定义字段

  字段是什么 字段的基本概念 定义：字段通常指的是数据的一个单独项，它可以是一个文本框、下拉菜单、复选框等，用于在用户界面上收集或展示数据。 用途：在表单中，字段用于收集用户输入；在表格或列表中，字段用于显示数据。 类型：字段可以有不同的类型，如文本、数字、日期等，这些类型通常由数据模型定义。 Oinone框架中的字段 在Oinone框架中，字段的设计和实现遵循以下原则： 后端模型驱动：前端的字段直接由后端的数据模型决定。这意味着后端定义了哪些数据应该展示，以及如何展示。 减少前后端联调：由于字段的定义和行为是由后端控制的，前后端的联调需求大大减少。前端开发者主要关注于如何呈现这些字段，而后端则负责数据的逻辑和结构。 灵活性与规范性：虽然Oinone推荐所有场景都遵循后端模型驱动字段的原则，以保持前后端的一致性和减少沟通成本，但它也为高度定制化的前端页面提供了灵活性。 元数据使用：Oinone可能还使用元数据来进一步定义字段的行为，例如它们是否可见、如何验证用户输入等。 结合前后端 在使用Oinone时，理解前后端如何合作来定义和展示字段是很重要的。这种方法不仅提高了开发效率，而且有助于确保数据的一致性和应用程序的可维护性。同时，对于那些需要特定定制或特殊处理的场景，开发团队能够灵活地适应这些需求，在遵守总体架构原则的同时进行一些特定的调整和优化。 作用场景 在Oinone框架中，字段扮演着连接后端数据模型和前端用户界面的重要角色。其作用场景包括但不限于以下几点： 业务组件的核心： Oinone集成了AntdDesignVue的全部UI组件，将它们转化为业务组件。这些业务组件以字段的形式存在，使得前端开发变得简单高效。开发人员可以直接使用这些现成的业务组件来构建用户界面，大大减少了开发工作量。 无代码开发支持： 字段的设计使得Oinone支持无代码开发。开发者可以通过拖拉拽的方式在前端快速构建界面，而后端模型的定义直接决定了这些界面的生成。这种模式简化了传统的前端开发流程，提升了开发效率。 个性化定制： 虽然标准的UI组件可以满足大部分需求，但复杂多变的业务场景往往需要更多个性化的处理。在Oinone中，开发者可以根据具体业务需求和公司的UI指南，定义专门针对特定行业或客户的定制化字段和组件。 与无代码平台的结合： Oinone允许将个性化的字段和组件与无代码平台相结合。这意味着即使在进行个性化定制时，也能保持使用无代码工具的便利性，实现更灵活、更高效的前端开发。 适应多维度业务需求： 由于字段在Oinone中的灵活性和可定制性，它们能够适应多维度的业务需求，无论是从UI设计、用户体验还是业务逻辑的角度，字段都能提供合适的解决方案 自定义字段 示例工程目录 以下是需关注的工程目录示例，main.ts更新导入./field： 图3-5-7-24 自定义字段工程目录示例 示例代码 创建自定义字段组件： 使用Vue框架创建一个新的组件（例如 CustomStringFieldVue），并定义其模板、脚本和样式。 在模板中定义字段的HTML结构。 在脚本中使用 defineComponent 来定义Vue组件。 字段类的定义： 导入必要的模块，如 FormFieldWidget, ModelFieldType, SPI, ViewType 等。 使用 @SPI.ClassFactory 装饰器来注册自定义字段。 在类内部初始化并设置组件。 SPI注册参数解释： viewType: 指定视图类型，如表单视图或搜索视图。 widget: 可以指定组件名称。 ttype: 字段的业务类型，例如字符串、数字等。 multi: 指明字段是否支持多值。 model: 定义字段所属的模型。 viewName: 指定视图名称。 name: 定义所属字段的名称。 import {FormFieldWidget, ModelFieldType, SPI, ViewType} from '@kunlun/dependencies'; import CustomStringFieldVue from './CustomStringField.vue'; @SPI.ClassFactory( FormFieldWidget.Token({ viewType: [ViewType.Form, ViewType.Search], ttype: ModelFieldType.String }) ) export class CustomStringField extends FormFieldWidget { public initialize(props) { super.initialize(props); this.setComponent(CustomStringFieldVue); return this; } } 图3-5-7-24 自定义字段组件(TS)示例 <template> <div class="custom-string-filed-wrapper"> 字段组件 </div> </template> <script lang="ts"> import { defineComponent } from 'vue' export default defineComponent({ inheritAttrs: false, name: 'CustomStringFieldVue' }) </script> <style lang="scss"> .custom-string-filed-wrapper { } </style> 图3-5-7-24 自定义字段组件(Vue)示例 效果 图3-5-7-24 自定义字段效果示例

  史, 昂

  2024年5月23日

  2.2K000