Oinone社区 作者：史, 昂原创文章，如若转载，请注明出处：https://doc.oinone.top/oio4/9315.html
访问Oinone官网:https://www.oinone.top获取数式Oinone低代码应用平台体验
5.1 CDM的背景介绍
上一篇
2024年5月23日 am8:23
4.5.2 研发辅助之SQL优化
下一篇
2024年5月23日
相关推荐
-
合作伙伴中心
合作伙伴中心包含“公司、个人、部门、岗位、员工”五个菜单。其中公司、个人为合作伙伴，是创建组织架构的前置条件；部门、岗位、员工为组织架构，是选择的公司下的内部架构。 合作伙伴 公司页面中包含常规的增删改查和查看详情。 公司的创建页面如下： 个人暂不支持创建。 组织架构 同样菜单中包含常规的增删改查和查看详情。 组织架构可以依次创建部门、岗位、员工。对应关系为，一个部门下有多个岗位，一个员工可以归属于多个部门和多个岗位。 部门创建页面如下： 岗位创建页面如下： 员工创建页面如下： 合作伙伴中心创建的员工会自动生成可登录的用户并进行绑定。 在用户中心创建的用户仅为可登录用户无法操作管理员工、关联部门。 流程设计器中可选到的操作人分类为“员工、部门、角色”。
-
5.8 商业支撑之执行域
一、基础介绍 执行域包括两个核心一是订单的产生，二是订单的履约。往往品牌商既有自营渠道（包括2c、2b）、又有第三方渠道。那么有两种设计思路： 把第三方渠道的订单当作自有渠道的订单产生一种特殊方式，开放订单创建接口，并统一履约。 好处：简单，在3方渠道不多、且自有渠道单一，并且逻辑相识时系统结构会简单 坏处： 当3方渠道的履约方式、库存分配方式、逆向逻辑等有差异时，会让自有渠道参杂很多不相干的逻辑引入不必要的复杂度 自有渠道不够独立和纯粹，自有渠道多样化时难以支撑 把商家自营渠道假设为特殊的第三方渠道，再建立统一的订单管理系统来对接渠道订单，并完成履约 好处：交易与履约逻辑分离，对未来发展有扩展性 坏处：引入一定复杂度 我们采用的是第二套方案，整体结构简易图如下 图5-8-1 方案整体结构简易图 二、模型介绍 图5-8-2 模型介绍 核心设计逻辑 首先我们看到上图交易域和履约域有很多相同父模型的子模型，交易域和履约域的父模型在CDM的在himalaya-trade里。履约域看oms（libra）对himalaya-trade扩展，交易域看b2c（leo）和b2b（aries）对对himalaya-trade扩展。libra、leo、aries是我们对上层业务产品的命名，取自黄道十二星座 交易域是多商家平台视角设计，有自身渠道必要的履约相关信息，完成自闭环。 履约域是从单一商家对接多渠道视角设计，有渠道交易订单同步后完成履约发货相关设计，完成自闭环。 履约域的合单拆单发货设计，渠道订单只能合单为履约单不可拆，履约单可以拆单发货不可合。用m2o和o2m的组合设计来降低难度，而非采用两个m2m的设计。
-
5.6 商业支撑之商品域
一、基础介绍 当业务在线化后，用于内部管理的产品主数据，叠加一堆销售属性变成了商品被推倒了前台，成为导购链路中最最重要的信息载体。看似最基础和最简单的商品模块也有很多门道。主要集中在以下几个方面： 商品的属性如何管理、呈现、参与导购（类目、搜索的过滤条件） 如何解决固定不变的内部管理需求与基于销售特性长期变化的运营需求之间的矛盾 在多渠道情况渠道商品，如何映射到实际sku进行履约 二、模型介绍 图5-6-1 模型介绍 类目属性，解决“商品的属性如何管理、呈现、参与导购（类目、搜索的过滤条件）” 前后台类目设计，解决“如何解决固定不变的内部管理需求与基于销售特性长期变化的运营需求之间的矛盾” 销售Sku和库存Sku设计，解决“在多渠道情况渠道商品，如何映射到实际sku进行履约” 要把这些问题搞清楚，得先把名词统一下： 领域 名称 oinone的定义 说明 举例 平台运营视角 Spu Product –>Spu2.1.9 –> 3.0.0 SPU(Standard Product Unit)：标准化产品单元。SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性 iPhone X可以确定一个产品 后台类目 后台类目(Category) 商品分类分级管理，以及规范该类目下公共属性可以分为普通属性、销售属性 比如类目：3c数码/手机销售属性：内存大小、颜色等普通属性：分辨率 前台类目 前台类目(FrontCategory) 平台导购类目 通过前台类目关联后台类目或后台类目属性，用于满足运营需求 大体上SPU处于最上层、Item属于下一级，而SKU属于最低一层。SPU是平台层面，Item是商家层面，SKU是商家的Item确定销售属性SPU非必须，在平台类交易中，平台方为了规范商家发布商品信息，进行统一运营时需要 商家销售视角 Item 渠道商品(Item) 简单来说是：SPU加上归属商家、以及商家自有的价格与描述 商家A的iPhone X Sku 销售Sku(SaleSku) SKU=Stock Keeping Unit（库存保有单位）。是对每一个产品和服务的唯一标示符，该系统的使用SKU的值根于数据管理，使公司能够跟踪系统，如仓库和零售商店或产品的库存情况。 iPhone X 64G 银色 则是一个SKU。 店铺类目 ShopCategory 商家店铺导购类目 在平台类电商，商家都会有自己独立的店铺主页，商家类目跟前台类目作用类似，只是局限影响范围为商家店铺内 销售SKU中会有一个InvSkuCode来关联InventorySku，比如：品牌上在不同渠道（淘宝、京东、自建电商）中会有不同的销售SKU，在从渠道同步销售SKU会根据外部code 商家管理视角 产品或库存Sku InventorySku 跟销售领域的sku的定义类似，但销售领域是为了规范购买行为，这里规范企业内部管理。 iPhone X 64G 银色 组合Sku InventorySkuComposition 空调有内外机组合而成，这就是一个组合sku 产品分类 ProductKind 企业内部管理划分 商品系列 ItemSeries 指互相关联或相似的产品，是按照一定的分类标准对企业生产经营的全部产品进行划分的结果。一个产品系列内往往包括多个产品项目。产品系列的划分标准有产品功能、消费上的连带性、面向的顾客群、分销渠道、价格范围等 存货类别 StorageKind 为了反映存货的组成内容，正确计算产品的生产成本以及销售成本，会计上必须对存货进行科学地分类，按存货的不同类别进行核算 表5-6-1 各领域名称说明
-
4.1.2 模块之启动指令
针对不同启动指令的组合可以满足不同场景需求，下面列举了几个常规组合方式，小伙伴们务必把这几种模式都尝试一遍，会更有体感 本节为小伙伴讲解oinone模块的几种启动方式，它是为能灵活地应对企业市场的不同场景需求，为op（本地化部署）、saas和研发提供个性化支撑。也为oinone独特性之单体与分布式的灵活切换提供基础支撑 一、部署参数 参数 名称 默认值 说明 -Plifecycle 生命周期部署指令 RELOAD 可选项：无/INSTALL/PACKAGE/RELOAD/DDL安装-install为AUTO；upgrade为FORCE打包-install为AUTO；upgrade为FORCE；profile为PACKAGE重启-install、upgrade、profile为READONLY打印变更DDL-install为AUTO；upgrade为FORCE；profile为DDL 表4-1-2-1 部署参数 如果在启动命令中配置了部署参数，可不再设置服务参数和可选项参数。下图为在启动命令中添加部署参数的示例。 图4-1-2-1 在启动命令中添加部署参数的示例 二、使用场景 针对不同启动指令的组合可以满足不同场景需求，下面列举了几个常规组合方式，小伙伴们务必把这几种模式都尝试一遍，会更有体感。 场景一：DDL(1)+RELOAD(N)应对专有DBA 因为很多公司数据库是由专门的DBA来管理的，不允许应用直接变更数据库相关配置、表结构、初始化数据。而oinone是基于元数据驱动的，任何模型、行为的变化都会自动转化成对物理存储的改变与元数据变化。 oinone为了适用企业op场景，特别增加了DDL模式。把发布上线分为两个步骤。 一：用DDL模式把涉及到数据库的变更与元数据初始化的脚本进行输出，交由客户公司DBA审批，并执行 二：用RELOAD模式，进行正常的应用重启工作，不进行安装、升级、以及数据库物理变革等操作。 #应用启动关闭自动DDL配置 pamirs.boot.profile: CUSTOMIZE pamirs.boot.options.rebuildTable: false pamirs.persistence.global.auto-create-database: false pamirs.persistence.global.auto-create-table: false 图4-1-2-2 应用启动关闭自动DDL模式 场景二：PACKAGE(1)+RELOAD(N)应对提升多机器实例效率 在机器规模相对大的场景中我们会碰到以下问题： 元数据差量计算、数据库变更、元数据变化保存都非常费时，如果每台机器都来一遍是非常费时费力的 分布式下多机器如果并发进行INSTALL，会导致数据库修改表结构、元数据变化保存锁死 所以我们可以选择一台机器用PACKAGE，其他机器采用RELOAD模式，做到合理规避问题，提升应用发布效率 场景三：INSTALL应对开发模式 研发在本地开发模式下INSTALL是最有效率的，把所需依赖模块一把启动和调试。 上线如果要用INSTALL需要注意，要逐台进行。当然也可以改进成INSTALL(1)+RELOAD(N)模式 三、启动命令解读 查看启动命令 可以在启动日志中查看当前所用启动命令。 图4-1-2-3 在启动日志中查看当前所用启动命令 生命周期管理-Plifecycle 除了通过启动YAML中pamirs.boot属性来设置启动参数，你还可以在应用启动命令中使用-Plifecycle参数来快捷控制模块生命周期的管理方式。该参数的可选项为RELOAD、INSTALL、CUSTOM_INSTALL、PACKAGE、DDL。 java -jar <your jar name>.jar -Plifecycle=RELOAD 启动命令优先级高于YAML中pamirs.boot属性中的install、upgrade和profile属性。如果不使用-Plifecycle参数，则使用YAML中pamirs.boot属性中的install、upgrade和profile属性配置。若YAML中未配置，则采用默认值。 启动配置项 默认值 RELOAD INSTALL CUSTOM_INSTALL PACKAGE DDL install AUTO READONLY AUTO AUTO AUTO AUTO upgrade AUTO READONLY FORCE FORCE FORCE FORCE profile CUSTOMIZE READONLY AUTO CUSTOMIZE PACKAGE DDL 表4-1-2-2 Plifecycle可选项与启动项对应表 profile属性请参考4.1.1【服务启动可选项】一文。只有pamirs.boot.profile=CUSTOMIZE时，在pamirs.boot.options中自定义的可选项才生效。 自动建表-PbuildTable java -jar <your jar name>.jar -PbuildTable=NEVER PbuildTable参数用于设置自动构建表结构的方式。如果不使用该参数，则options属性的默认值请参考4.1.1【服务启动可选项】一文。-PbuildTable参数可选项为： NEVER – 不自动构建表结构，会将pamirs.boot.options中的diffTable和rebuildTable属性设置为false EXTEND – 增量构建表结构，会将pamirs.boot.options中的diffTable属性设置为false，rebuildTable属性设置为true DIFF – 差量构建表结构，会将pamirs.boot.options中的diffTable和rebuildTable属性设置为true 模块在线 -PmoduleOnline java -jar <your jar name>.jar -PmoduleOnline=CHECK PmoduleOnline参数用于设置模块在线的方式。如果不使用该参数，则profile属性的默认值请参考4.1.1【服务启动可选项】一文。-PmoduleOnline参数可选项为： NEVER – 不读取存储在数据库中的模块信息，会将pamirs.boot.options中的reloadModule和checkModule属性设置为false READ – 读取存储在数据库中的模块信息，会将pamirs.boot.options中的checkModule属性设置为false，reloadModule属性设置为true CHECK – 读取存储在数据库中的模块信息并校验依赖模块是否已安装，会将pamirs.boot.options中的reloadModule和checkModule属性设置为true 元数据在线-PmetaOnline java -jar <your jar name>.jar -PmetaOnline=MODULE PmetaOnline参数用于设置元数据在线的方式，如果不使用该参数，则profile属性的默认值请参考4.1.1【服务启动可选项】一文。-PmetaOnline参数可选项为： NEVER – 不持久化元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为false MODULE – 只注册模块信息，会将pamirs.boot.options中的updateModule属性设置为true，reloadMeta和updateMeta属性设置为false ALL – 注册持久化所有元数据，会将pamirs.boot.options中的updateModule、reloadMeta和updateMeta属性设置为true 开放远程服务-PenableRpc PenableRpc参数用于设置是否开启远程服务。如果不使用该参数，则profile属性的默认值请参考4.1.1【服务启动可选项】一文。-PenableRpc参数可选项为true和false。该参数会将参数值设置到pamirs.boot.options中的publishService属性。 开启API服务-PopenApi PopenApi参数用于设置是否开启HTTP API服务。如果不使用该参数，则profile属性的默认值请参考4.1.1【服务启动可选项】一文。-PopenApi参数可选项为true和false。该参数会将参数值设置到pamirs.boot.options中的rebuildHttpApi属性。 开启字段校验-PcheckField PcheckField参数用于设置是否开启字段校验。-PcheckField参数可选项为true和false。由于通常应用的字段数量非常多，会延长系统启动时长，所以默认不会开启字段校验。 启用数据初始化服务-PinitData PinitData参数用于设置是否开启数据初始化服务。如果不使用该参数，则profile属性的默认值请参考4.1.1【服务启动可选项】一文。-PinitData参数可选项为true和false。该参数会将参数值设置到pamirs.boot.options中的updateData属性。 四、不使用自动构建数据库表功能 Oinone LCDP默认提供框架的所有服务，所以会自动构建数据库表。如果不需要使用Oinone的存储构建服务，可以设置YAML文件中关于自动建表的配置。这样就不会动态构建数据库表，你可以手动搭建数据库表。 通过配置启动YAML中pamirs.boot.options.rebuildTable为false彻底关闭自动建表功能。 pamirs: boot: options: rebuildTable: false 图4-1-2-4 不使用自动构建数据库表功能 也可以按需配置启动YAML中pamirs.persistence配置来关闭部分数据源的自动建表功能。persistence配置既可以针对全局也可以分数据源进行配置。 pamirs: persistence: global: # 是否自动创建数据库的全局配置，默认为true autoCreateDatabase: true # 是否自动创建数据表的全局配置，默认为true autoCreateTable: true <your ds key>: # 是否自动创建数据库的数据源配置，默认为true autoCreateDatabase: true # 是否自动创建数据表的数据源配置，默认为true…