蒋江伟

相关推荐

• 4.2 前端高级特性

  史, 昂

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

  1.6K000
• Oinone 7天入门到精通

  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.1K000

• 第1章 揭开面纱，理解Oinone

  本章旨在从以下几个维度逐步揭开Oinone的面纱，让大家了解Oinone的初心与愿景，以及它是如何站在软件领域的巨人肩膀上，结合企业数字化转型的深入，形成全新的理念，帮助企业完成数字化转型。 具体来说，本章会从以下四个方面逐一展开： Oinone的初心与愿景：结合中国软件行业的发展与自身职业发展经历，探讨Oinone为何诞生以及其愿景是什么。 Oinone致敬西方软件行业的新贵odoo：介绍Oinone的灵感来源，探究Oinone与odoo的异同，以及如何从odoo中汲取经验。 从企业转型困境，引出Oinone新的思路：通过剖析企业数字化转型的困境，引出Oinone提出的全新思路，以及如何应对企业数字化转型的挑战。 行业对比，让您从不同视角理解Oinone：通过与同行业产品进行对比，从不同的视角深入理解Oinone的特点和优势。

  史, 昂

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

  3.1K001
• Oinone 7天入门到精通

  1.3 Oinone的生态思考

  以“企业级软件生态”的方式去帮助企业建立“一站式的商业智能软件”。 通过观察信息化到数字化的软件行业发展历程（如下图1-3所示），我们可以发现，企业真正需要的是一站式的软件产品。然而，一站式的软件产品往往都是从单个领域的需求满足开始，这在信息化时代和数字化时代都是如此。在信息化时代，以ERP为终点的一站式趋势逐渐形成；而在数字化时代，中台概念的提出则标志着一站式的趋势重新开始。本文将从企业数字化转型所面临的困境出发，探讨Oinone的生态思考。 图1-3 从信息化到数字化软件行业发展历程 1.3.1 与中台的渊源 中台概念的提出标志着企业数字化改造进入了一个新的时代。随着数字化转型不断深入，企业面临着严重的数据割裂、系统隔离等问题。在这样的背景下，“敏捷响应，低成本地快速创新”成为了推动一站式商业智能软件的内在诉求。需要澄清的是，互联网中台架构只是一种企业解决数据割裂、系统隔离，建立一站式商业智能软件的技术概念之一，并不是技术标准。而且这种方式只适用于企业自建模式。在多供应商环境下，则会适得其反，导致建立更复杂的烟囱系统。 阿里于15年提出中台架构概念，抓住了企业数字化转型的核心诉求，即“敏捷响应，低成本快速创新”。然而，阿里作为一家生态公司，在16年时基本上是带着合作伙伴来给企业交付，但由于伙伴对互联网技术的理解和能力的限制，基本上都做得不好，甚至失败。在2017年，阿里成立了原生交付团队，希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。在做完几个客户后，我发现阿里也做不好，但这次做不好的原因不是技术不行或项目上不了线，而是上线以后预期的效果没有达到，其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候，所谓的目标“敏捷响应，快速创新”就无从说起了。结果客户会反馈以下三类问题： 不是说敏捷响应吗？为什么改个需求这么慢，不但时间更长，付出的成本也更高了？是因为中台架构需要一定的技术能力和经验才能有效地应用，就像一个只会骑自行车的人给他一辆汽车或者飞机，他也不能驾驭它们，更不用说是手动挡的。 不是说能力中心吗？当引入新供应商或有新场景开发的时候，为什么前期做的能力中心不能支撑了？是因为能力中心是一种面向业务的能力组织方式，它将不同的业务能力抽象出来，以服务的形式对内提供。然而，由于业务场景的差异，不同的业务需要的能力也会不同，因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发，需要根据实际情况对能力中心进行定制化和扩展化，但谁来负责呢？新项目的供应商还是客户自己？ 不是说性能好吗？为什么我投入的物理资源更多了？是因为中台架构采用微服务来解决单点瓶颈问题，提高系统性能和可用性，但是在初始阶段，投入的资源可能会更多。每个模块至少需要两个实例来保障高可用性，因此物理资源的投入量可能会比以前更多。 1.3.2 找解决方案 在考虑解决方案之前，我们需要思考企业数字化软件的最终状态将是什么样子。目前有两种主要的方案（如下图1-4所示）： 第一种是以自建研发团队为核心。中国的大型企业已经开始尝试这种模式，看起来似乎是一个时下比较流行的可行性方案。然而，绝大多数企业由于成本、人才团队等原因而难以坚持下去，只能与供应商合作开发。 第二种是以供应商为核心。由于大多数企业无法选择第一种路径，他们必须接受目前分散的情况，并通过系统集成尽可能拉通各个系统。尽管如此，在数字化时代中，真正意义上的一站式商业智能软件供应商还未出现。 图1-4 企业数字化桎梏和囹圄 对企业来说，这两种方案都非常艰难，但在大规模数字化历程中又不得不做出选择。此外，我们还能清晰看到以下几点： "敏捷响应，低成本地快速创新"成为企业推动一站式商业智能软件的内在诉求 目前没有一家软件供应商能满足企业所有外围商业场景，也不可能有这样的供应商 绝大部分企业需要软件供应商，而不是自建 如何突破这种局面也成为中国软件行业发展的一个机遇。因此，我的思考是： 我们的目标不是依托于提升研发人员的能力，而是降低互联网架构的门槛，让更多企业真正拥有“敏捷响应，低成本快速创新”的能力。 我们的目标不是输出中台方法论，而是提供中台建设的技术平台。 我们的目标不是只服务大企业，而是真正赋能不同IT组织能力的企业，让它们都具备持续创新的能力。 今天，许多中台软件公司告诉企业：“中台是持续演进和快速迭代的过程，因此企业需要组建中台架构团队来实现，而他们则通过中台项目落地将中台建设方法论传授给企业。”这句话的前半部分是正确的，因为我们之前提到企业需要具备敏捷响应业务的能力，即应变能力，因为应变是不断变化的。然而，后半部分是不正确的，因为今天的企业已经有能力组建团队，那么这些中台软件公司到底有什么用呢？企业真的缺少方法论吗？在19年，我就提出了自己的看法：没有低代码能力的中台公司都在收取智商税，都在欺诈，因为很多企业根本找不到足够懂互联网架构的人才。明白流氓在哪里了吗？这些流氓公司赚了很多钱，最后责怪企业无法招到人才，这是企业的责任。因此，仍然认为“最好的赋能是降低门槛，而不是让客户提高技术水平”。 最终，我们得出了一个服务模式的想法：构建企业级的软件生态。企业级软件生态的确切定义是：通过开放的方式，让企业本身以及不同的软件供应商共同参与，遵循相同的技术和数据规范，打造一体化、无需集成的各类企业级软件。如果要打造企业级软件生态，我们列出了六个要点（如下图1-5所示）。 图1-5 打造企业级软件生态需要具备的六大能力 我很幸运地有机会通过“企业级软件生态”的方式，为企业建立“一站式的商业支持平台”提供帮助。我们的Oinone平台结合了低代码开发、通用数据模型和业务产品的优势（如下图1-6所示）。 图1-6 Oinone = 低代码开发平台 + 通用数据模型 + 业务产品 我们对Oinone一站式低代码商业支撑平台展开介绍，它大致分为4部分： 以低代码开发平台为基础，输出具备互联网架构下的软件快速开发标准。这可以帮助企业快速构建符合互联网架构标准的应用程序，从而实现快速响应和低成本创新。 以通用数据模型为基础，满足不同软件基于同一套数据标准的扩展能力。这可以确保不同软件系统之间的数据兼容性和互操作性，避免数据孤岛和信息隔离。 在业务产品层面上，企业和伙伴基于相同的技术标准和数据标准共同提供解决方案。这可以帮助企业和伙伴共同开发出符合标准的商业支撑平台，以提高业务效率和创新能力。 最后是无代码设计器，用于满足项目开展中，超出业务标品范围之外的需求，或者针对标品的临时需求。这可以帮助业务人员在不需要专业软件支持的情况下，自主解决业务需求，并支持部门间的协同工作。 1.3.3 生态建设 Oinone致力于打造全球最大的无需集成的商业应用程序及其生态系统，通过开源内核、汇集数千名开发人员和业务专家，为企业提供成本效益、一体化、模块化的解决方案，解决所有商业需求，让不同技术之间的合作变得简单易行，摆脱烦恼的集成问题。 在客户和场景领域，我们严格限定了自身的专注领域。针对超大型头部企业，我们专注于树立标杆，而对于大、中、小型企业，则交由我们的伙伴来支持。小微企业可以通过我们的开源社区版获得覆盖。在企业数字化转型的核心领域中，我们的解决方案涵盖了数字化交易场景、全渠道订单履约场景、数字化采购场景、数字化营销等产品。在其他领域，我们完全交由伙伴来建设。由于我们自身在企业协同商务领域拥有深厚的背景，因此在该领域提供的产品拥有特别的优势。 企业数字化转型核心领域 图1-7 企业数字化转型核心领域

  史, 昂

  2024年5月23日

  2.0K000
• Oinone 7天入门到精通

  3.5.7.1 基础概念

  模块(module) 概念 在 Oinone 系统的架构中，模块（module）是核心组成元素之一，可以被理解为域（domain）的一个具象化概念。模块的来源有两种：一种是基于后端代码定义，另一种是通过无代码新增。具体的代码定义方式，请参考“[占位符]”，而无代码定义的相关信息则可在“[占位符]”找到。在 Oinone 体系中，模块对应两种实体：模块和应用。 模块： 这是一类特定能力的集合，它可以依赖其他模块，也可以被其他模块依赖。 应用： 它是一种特殊的模块，具备模块的所有特性，并在此基础上可被终端用户访问。 使用 在前端开发中，module通常以应用的形式出现，它们往往对前端用户保持透明。在接下来的讨论中，我们主要围绕应用来探讨module的使用。从应用的角度出发，我们可以在前端开发中识别出以下几种典型使用场景，并通过具体的业务案例来加以说明 应用菜单扩展： 实现自定义母版来定义特定应用的菜单 表格布局扩展： 用于自定义布局的工具，以定义特定应用的表格布局 在这些场景中，我们着重实现了应用层面的隔离，确保每个模块都能在应用的维度上独立运作 查找 在实际业务开发中，有3个方式可以找到应用 浏览器url查找(查找速度快，可能不准) 图3-5-7-1 浏览器url查找模块(module) 接口返回查找 第一步找到截图类似请求 图3-5-7-2 接口找到viewActionQuery 第二步根据返回找应用 图3-5-7-3 接口返回查找模块(module) vue调试器选中对应的组件查找 图3-5-7-4 vue调试器查找模块(module) 推荐使用浏览器url查找，若与预期不符，可用另外两种方式查找 模型(model) 概念 在 Oinone 系统的架构中，模型（model）是另一个关键核心组成部分。模型在业务层面主要体现之一为数据库的实体表，它是承载业务实现的基础结构。要了解模型的详细介绍，请参考“[占位符]”，前端所用的模型，对应后端代码定义来说，代表的是模型的编码。 关于模型的定义，我们提供了两种方法： 代码定义： 对于需要通过编程实现的模型定义，您可以参考“[占位符]”来了解具体的代码实现方法； 无代码定义：如果您倾向于使用无代码工具来定义模型，具体的操作和流程可以在“[占位符]”中找到 使用 在前端开发中，模型是前端运行的必要条件，以下场景中，模型不直接感知: 视图渲染 页面之间跳转交互 与后端交互 以下场景中，模型会直接决定前端的渲染逻辑 母版扩展：为某模型扩展母版 布局扩展：为某模型扩展布局 页面扩展：为某模型扩展个性化页面 字段扩展: 扩展字段时加上模型的范围 动作扩展: 扩展动作时加上模型的范围 以上场景中，涵盖了前端工作的方方面面，在OInone体系中，模型不止是后端运行得基础，同样也决定了前端如何运行，那这样做有什么好处呢？ 前后端几乎不需要联调，联调的协议用模型来承载 前端无需定义路由、权限埋点 查找 在实际业务开发中，有3个方式可以找到模型 浏览器url查找 图3-5-7-5 浏览器url查找模型(model) 接口返回查找 第一步找到类似截图请求 图3-5-7-6 接口找到viewActionQuery 第二步根据返回找模型 图3-5-7-7 接口找到viewActionQuery vue调试器选中对应的组件查找 图3-5-7-8 vue调试器查找模型(model) 动作(action) 概念 动作(action)定义了终端用户得交互，它描述了前端与前端、前端与后端之间的交互。 动作涵盖了前端以下部分: 页面跳转(router) 调用后端接口 页内交互(打开弹窗、打开抽屉) 它有两部分的来源: 模型内定义动作 窗口动作(页面跳转、打开弹窗、打开抽屉) 服务器动作(调接口) 前端定义客户端动作，可自定义其它逻辑，例如: 把选中行的某一列数据复制一下 使用 动作的使用绝大部分的情况是由平台自动执行的，在平台执行不符合预期时可以使用自定义动作自行扩展 查找 vue调试器选中对应的组件查找 选中服务器动作(ServerAction) 图3-5-7-9 vue调试器查找服务器动作(ServerAction) 选中窗口动作(ViewAction) 图3-5-7-10 vue调试器查找窗口动作(ViewAction) 字段(field) 概念 在我们的后端模型中，字段（Field）是核心的定义元素，它们在数据库中表现为数据表的列。更重要的是，这些字段在前端应用中发挥着数据传输的关键作用。例如，当前端需要调用后端接口时，它会发送如下结构的数据： 图3-5-7-11 name字段数据举例 这里的 "name" 是一个字段实例，它连接了前后端的交互。在后端，该字段不仅用于数据存储，也参与逻辑运算。 字段在 Oinone 系统中的加强应用 在 Oinone 系统中，字段的功能得到了扩展。除了基本的前后端数据交互，字段的定义还直接影响前端的用户界面（UI）交互。例如： 前端交互组件的选择：前端交互组件的类型取决于字段的数据类型。对于 String 类型的 "name" 字段，前端会使用输入框来收集用户输入的 "张三"。 数据存储和类型定义：在后端，"name" 字段被明确定义为 String 类型，这决定了它如何存储和处理数据。 字段与前端组件定义的解耦 一个关键的设计原则是，前端组件的定义与具体的字段值或字段名（如 "name" 或 "张三"）不直接相关，而是基于字段的数据类型（此例中为 String）。这种设计实现了： 前端组件的一致性：确保所有组件的输入输出遵循同一数据类型（如 String）。 高度的组件复用性：在满足 UI 要求的前提下，任何 String 类型的字段都可以使用这种通用的组件设计。 使用 Oinone 系统中的视图与字段交互的灵活性 Oinone 系统为每种视图和字段类型（Ttype）提供了默认的交互模式。这不仅保证了前端工程启动时所有界面的即时展示，也为开发者带来了高度的灵活性和扩展能力。以下是这一设计理念的关键点： 1. 视图与字段交互的默认实现 每种视图都有对应字段类型（Ttype）的默认交互实现，确保用户界面一致且直观。这使得在前端工程启动时，所有界面能够无需额外配置即可正常展示。 2. 灵活性与扩展能力 尽管系统提供了默认的交互方式，开发者仍然拥有自定义这些交互方式的能力。这意味着开发者可以根据应用需求，设计更加贴合业务逻辑和用户体验的交互模式。 3. 覆盖和替换默认组件 最为重要的是，开发者不仅可以添加新的交互方式，还可以完全覆盖和替换系统的默认组件。这提供了极大的自由度，使开发者能够根据具体场景重新设计和实现界面组件，从而达到完全定制化的用户体验。 查找 vue调试器选中对应的组件查找 图3-5-7-12 vue调试器查找字段(field) 视图类型(viewType) 概念 在 Oinone 系统中，视图是模型在前端的具体表现形式。视图的核心组成和功能如下： 1. 组成要素 字段：视图中的字段代表了模型的数据结构，它们是界面上数据显示和交互的基础。 动作：视图包含的动作定义了用户可以进行的操作，如添加、编辑、删除等。 前端UI：视图的界面设计，包括布局、元素样式等，决定了用户的交互体验。 2. 数据源与交互 数据源：视图的数据直接来源于后端模型。这意味着前端视图展示的内容是根据后端模型中定义的数据结构动态生成的。 交互：视图不仅展示数据，还提供与数据交互的能力。这些交互也是基于后端模型定义的，包括数据的增删改查等操作。 3. 灵活性 视图可以灵活选择是否采用模型的交互。这意味着开发者可以根据需求决定视图仅展示模型的数据，或者同时提供与数据的交互功能。 使用 在 Oinone 系统中，用户可以通过无代码界面设计器轻松配置视图。系统内置了以下主要视图类型： 表格（Table） 表单（Form） 详情（Detail） 搜索（Search） 画廊（Gallery） 树（Tree） 界面设计器配置…

  史, 昂

  2024年5月23日

  1.4K000