Oinone在技术方面通过整合互联网架构和低代码技术，实现了三个独特的关键创新点（如图2-5所示）：
独立模块化的个性化定制：每个需求都可以被视为一个独立的模块，从而实现个性化定制，提高软件生产效率。此外，这些独立模块也不会影响产品的迭代和升级，为客户带来无忧的体验。
灵活的部署方式：单体部署和分布式部署的灵活切换，为企业业务的发展提供了便利，同时适用于不同规模的公司，有助于有效地节约企业成本，提升创新效率，并让互联网技术更加亲民。
低代码和无代码的结合：低无一体为不同的IT组织和业务用户提供了有效的协同工作方式，能够快速部署安全、可扩展的应用程序和解决方案，帮助企业/组织更好地管理业务流程并不断优化。
Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9219.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
1.数据类 1.1 新增数据 新增数据节点可以为任意模型通过表达式新增数据，包含两种模式，「节点执行完即增加业务数据」功能下新增的数据也可以同步触发流程，相反「节点执行完不增加业务数据」则不会触发新增业务数据关联的流程，数据仅可用于后续流程使用。 流程增加的数据在节点执行时就生效。 1.2 更新数据 更新数据节点可以为任意模型通过表达式更新数据。 1.3 获取数据 当流程需要调用触发模型之外的模型中的数据时就需要使用获取数据的功能。 需要选择获取单条/多条数据，选择一个获取数据的模型，可以设置一些筛选项减少不必要的数据。最后需要设置未获取到数据时的执行方式。 继续执行：跳过本次数据获取，继续执行流程。 向模型中新增数据后继续执行：新增数据来供后续节点使用，新增数据同时存入数据库中。 终止流程：终止流程将结束该流程，不管之后是否还有流程节点。 1.4 删除数据 删除数据节点可以将流程节点上面的模型数据从数据库中删除。 1.5 更新流程参数 可以将「流程配置」中的「流程参数」进行修改，仅有变更过的流程参数才能其他节点选中。 1.6 引用逻辑 可以在流程中使用模块自带的逻辑或使用低代码设计的逻辑。
如果说低代码开发框架输出技术标准，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思路示意图
占在巨人的肩膀上，天地孤影任我行 1.2.1 数字化时代Oinone接棒Odoo 在数字化时代，中国在互联网化的应用、技术的领先毋庸置疑，但在软件的工程化、产品化输出方面仍有许多改进的空间。这时，我了解到了Odoo——一个国外非常优秀的开源ERP厂商，全球ERP用户数量排名第一，百级别员工服务全球客户。Odoo的工程化能力和商业模式深深吸引了我，它是软件行业典型的产品制胜和长期主义者的胜利之一。 在2019年，也就是数式刚成立的时候，我们跟很多投资人聊起公司的对标是谁，我不是要成为数字化时代的SAP，而是要成为Odoo。然而，当时大部分国内投资人并不了解Odoo，尽管它已经是全球最大的ERP厂商之一，因为当时Odoo还没有明确的估值。直到2021年7月份获得Summit Partners的2.15亿美元投资后，Odoo才正式成为IT独角兽企业。 Odoo对我们提供了极大的启示，因此我们致敬Odoo，同样选择开源，每年对产品进行升级发布。如今，Odoo15已经发布，而Oinone也已推出第三版，恰好相隔12年，这是一个时代的接棒，从信息化升迁至数字化。 1.2.2Oinone与Odoo的不同之处 技术方面的不同 在技术上，Oinone和Odoo有相同之处，也有不同之处。它们都基于元数据驱动的软件系统，但是它们在如何让元数据运作的机制上存在巨大差异。Odoo是企业管理场景的单体应用，而Oinone则致力于企业商业场景的云原生应用。因此，它们在技术栈的选择、前后端协议设计、架构设计等方面存在差异。 场景方面的不同 在场景上，Oinone和Odoo呈现许多差异。相对于SAP这些老牌ERP厂商，Odoo算是西方在企业级软件领域的后起之秀，其软件构建方式、开源模式和管理理念在国外取得了非凡的成就。然而，在国内，Odoo并没有那么成功或者并没有那么知名。国内做Odoo的伙伴普遍认为，Odoo与中国用户的交互风格不符，收费模式设计以及外汇管制使商业活动受到限制，本地化服务不到位，国内生态没有形成合力，伙伴们交流合作都非常少。另外，Odoo在场景方面主要围绕内部流程管理，与国内老牌ERP如用友、金蝶重叠，市场竞争激烈。相比之下，Oinone看准了企业视角由内部管理转向业务在线、生态在线（协同）带来的新变化，聚焦新场景，利用云、端等新技术的发展，从企业内外部协同入手，以业务在线驱动企业管理流程升级。它先立足于国内，做好国内生态服务，再着眼未来的国际化。 无代码设计器的定位 在无代码设计器的定位上，Odoo的无代码设计器是一个非常轻量的辅助工具，因为ERP场景下，一个企业实施完以后基本几年不会变，流程稳定度非常高。相反，Oinone为适应"企业业务在线化后，所有的业务变化与创新都需要通过系统来触达上下游，从而敏捷响应快速创新"的时代背景，重点打造出五大设计器。（如下图1-2所示）。 图1-2 Oinone五大设计器 在数字化时代中国软件将接棒世界，而Oinone也要接棒Odoo，把数字化业务与技术的最佳实践赋能给企业，帮助企业数字化转型不走弯路！
GraphQL 是一个用于 API 的查询语言，是一个使用基于类型系统来执行查询的服务端运行时（类型系统由你的数据定义）。GraphQL 并没有和任何特定数据库或者存储引擎绑定，而是依靠你现有的代码和数据支撑。 一个 GraphQL 服务是通过定义类型和类型上的字段来创建的，然后给每个类型上的每个字段提供解析函数。例如，一个 GraphQL 服务告诉我们当前登录用户是 me，这个用户的名称可能像这样： type Query { me: User } type User { id: ID name: String } 图4-1-17-1 GraphQL定义类型和字段示意 一并的还有每个类型上字段的解析函数： function Query_me(request) { return request.auth.user; } function User_name(user) { return user.getName(); } 图4-1-17-2 每个类型上字段的解析函数示意 一旦一个 GraphQL 服务运行起来（通常在 web 服务的一个 URL 上），它就能接收 GraphQL 查询，并验证和执行。接收到的查询首先会被检查确保它只引用了已定义的类型和字段，然后运行指定的解析函数来生成结果。 例如这个查询： { me { name } } 图4-1-17-3 GraphQL查询请求示意 会产生这样的JSON结果： { "me": { "name": "Luke Skywalker" } } 图4-1-17-4 GraphQL查询结果示意 了解更多 https://graphql.cn/learn/
因为默认视图很难满足客户的个性化需求，所以日常开发中view的配置是避免不了的。本系列篇是比较全面地介绍View配置的各个方面涉及：视图、字段、动作、布局等
