标准中心
标准中心承载了平台商品标准的元数据，目的在于让平台的商品更加的规范
总体设计
此处列出标准中心的顶层设计，内部域的划分，域之间的关系。是哪个的子域？
| 业务模块 | 解决问题域 |
|---|---|
| 类目体系 | 解决产品分类问题 |
| └ 后台类目 | 解决卖家产品分类问题，便于管理 |
| └ 前台类目 | 解决买家产品筛选分类问题，便于产品筛选购买 |
| └ 采购目录 | 解决财政产品分类问题，便于分好类做监管 |
| └ 协议商品类目 | 解决财政按区划等维度自定义产品分类的问题，主要用于定义服务类产品分类 |
| 属性体系 | 解决产品结构化信息表达的问题 |
| └ 属性库 | 解决产品结构化特性表达的问题 |
| └属性值库 | 解决产品结构化特性值表达的问题 |
| └品牌库 | 属性值库的特例，即品牌属性值库 |
| └型号库 | 属性值库的特例，即型号属性值库。目前平台未维护 |
| └类目属性 | 描述特定分类下产品共有特性 |
I、类目体系
一二三面向产品、四五六等面向技术。
一、业务背景
类目的业务背景是什么？类目即商品的分类，一个小分类就代表了消费者的一种需求，类目的产生是为了解决线下产品分类的问题（如超市里面的生鲜类、电器等），良好的产品分类结构可以便于更好的对产品进行管理。产品分类有国家标准定义，参见GB/T 7635。政采云平台的类目一方面参考了国标，另一方面又借鉴了其他成熟电商如淘宝等平台。类目按粒度分，又可以细分为一级类目、二级类目、三级类目等，组合成一个树形结构，其中一级类目最粗，越下级的类目约精细。类目的设计理念可以借鉴生物分类：届门岗目科属种，所遇到的问题也相似的，如会存在和熊猫一样，即不是熊又不是猫，单列熊猫科。
其中国标的类目共有六级，见下表
X X X X X * XXX --- 代码
| | | | | |
| | | | | |--------第六层 细类
| | | | |-------------第五层 小类
| | | |----------------第四层 中类
| | |-------------------第三层 大类
| |----------------------第二层 部类
|-------------------------第一层 大部类
举例说明，大部类如 0 为 农林（牧）渔业产品，01为种植业产品，011为谷物、杂粮等及其种子，0111为小麦及混合麦，01111为小麦，01111 * 012为 白色软质冬小麦，其树形结构图如下所示。
0 1 1 1 1 * 012 --- 代码
| | | | | |
| | | | | |--------第六层 细类，白色软质冬小麦
| | | | |-------------第五层 小类，小麦
| | | |----------------第四层 中类，小麦及混合麦
| | |-------------------第三层 大类，谷物、杂粮等及其种子
| |----------------------第二层 部类，种植业产品
|-------------------------第一层 大部类，农林（牧）渔业产品
产品类目在政采云平台称之为后台类目，不同于国标的六级类目，政采云中的类目使用了四层级类目（因为售卖的品类比国标要少），兼顾了类目管理的复杂度和分类的精准度。
后台类目的主要面向用户是生产产品的厂家或者代理产品售卖的供应商，其分类非常专业，而对于买方这种小白来说，不具备这种专业的分类知识，进行商品的筛选和购买也会变得非常困难。因此，按解决谁的问题中谁的不同，类目又细分为前台类目（解决买家认知商品和运营运营买家购买商品）、后台类目（解决卖家管理商品）、采购目录（政府采购业务特有，解决财政按财政的产品类目对商品进行监管）、协议商品类目（解决财政按区划等维度自定义产品分类的问题）。而为了让不同的用户的分类标准可以相互”认识“，平台又需要去维护不同的类目的映射关系，目前平台中的类目映射关系如下表（~代表重复）。
| 后台类目 | 前台类目 | 采购目录 | 协议商品类目 | |
|---|---|---|---|---|
| 后台类目 | N/A | Y | Y | ? |
| 前台类目 | ~ | N/A | N | ? |
| 采购目录 | ~ | ~ | N/A | Y |
| 协议商品类目 | ~ | ~ | ~ | N/A |
从广义上看，类目体系可以解决一切分类的问题，目前类目在平台中的作用主要为解决商品的分类问题，因此其为商品中心的一个子域。如果未来类目拿去解决商品域之外的分类问题了，那么它可以沉淀为一个更基础的业务模块。
二、业务模型
从小章节一中业务背景可以看出，类目体系的业务模型有两个特点：一是树形结构，二是其之间可以进行跨层级的多对多映射，以前后台类目及其映射举例，其业务模型可以表达为如下图：
三、平台现状
此章截取平台现有的业务界面，其中截图一为平台现有的后台类目管理页，截图二为前后台类目映射关联页。
四、业务关联
此章节罗列类目体现和平台中其他模块的业务关联关系。
| 业务模块 | 和类目体系的关联 |
|---|---|
| 商品 | 解决商品分类问题，其中后台类目主要用于供应商商品发布 |
| 采购目录 | 和后台类目对对多映射，解决财政产品类目和平台类目的不一致问题。 |
| 属性 | 类目和属性关联成为类目属性 |
| 前台大厅 | 消费前台类目树配置，渲染前台类目树用于导购 |
五、UML建模
用例图：
六、物理模型
为方便查看，仅列出关键字段
后台类目表（parana_back_categories）
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | 自增id | bigint(20) unsigned | PRI | NO | |
| 2 | code | 可读的code, 全局唯一(应用保证) | varchar(20) | YES | ||
| 3 | pid | 父级id | bigint(20) | YES | ||
| 4 | name | 名称 | varchar(256) | MUL | YES | |
| 5 | level | 级别 | tinyint(1) | YES | ||
| 6 | status | 状态,1启用,-1禁用(删除),0冻结,2下线 | tinyint(1) | YES | ||
| 7 | has_children | 是否有孩子 | tinyint(1) | YES | ||
| 8 | has_spu | 是否有spu关联 | tinyint(1) | YES | ||
| 12 | tags | 类目标签 | varchar(512) | YES | ||
| 15 | leaf_flag | 叶子节点标记 | varchar(200) | YES | ||
| 16 | index | 类目顺序 | bigint(20) | YES | 0 |
前台类目表（parana_front_categories）
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | 自增id | bigint(20) unsigned | PRI | NO | |
| 2 | pid | 父级id | bigint(20) | YES | ||
| 3 | name | 名称 | varchar(50) | MUL | YES | |
| 4 | level | 级别 | tinyint(1) | YES | ||
| 5 | tag_id | 前台类目标签 | bigint(20) | MUL | YES | |
| 6 | status | 1:正常；-3：删除 | tinyint(1) | YES | 1 | |
| 7 | has_children | 是否有孩子 | tinyint(1) | YES | ||
| 8 | logo | logo | varchar(256) | YES | ||
| 11 | leaf_flag | 叶子节点标记 | varchar(200) | MUL | YES | |
| 12 | index | 前台类目排序 | bigint(20) | MUL | YES | 0 |
前后台叶子类目映射表（parana_category_bindings）
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | bigint(20) unsigned | PRI | NO | ||
| 2 | front_category_id | 前台叶子类目id | bigint(20) | MUL | YES | |
| 3 | back_category_id | 后台叶子类目id | bigint(20) | YES | ||
| 4 | tag_id | 前台类目标签id | bigint(20) | MUL | YES | |
| 5 | status | 1：正常，-3:删除 | tinyint(1) | YES |
七、API服务
此处不列现状，列预期的设计。此处把逻辑点也列上。
八、多租户设计
九、其他技术文档链接
十、Reference
I、属性体系
属性在wiki上的定义为“共同的特征和特点”，如人的性别、文件的大小都是属性。平台中的属性体系主要包括两大块：一个是属性库，另一个是属性值库。还有一个类目属性，是属性体系和类目体系产生关联关系后的产物。
| 业务模块 | 解决问题域 |
|---|---|
| 属性库 | 解决产品结构化特性表达的问题 |
| 属性值库 | 解决产品结构化特性值表达的问题 |
| 品牌库 | 属性值库的特例，即品牌属性值库 |
| 型号库 | 属性值库的特例，即型号属性值库。目前平台未维护 |
| 类目属性 | 描述特定分类下产品共有特性 |
一、业务背景
相比于传统零售销售实际的可触摸的产品，电商销售的是信息化的商品。属性库正是用于解决商品的信息如何结构化问题的产物。试想我们一般如何描述一个商品？比如显示器我们会这样描述：屏幕大小为24寸，刷新频率为144HZ，屏幕比例为21比9等。其中我们把屏幕大小、屏幕尺寸和刷新频率称之为属性（特征），24寸、144HZ、21比9称之为属性的值。而一个商品即为一系列属性和属性值的集合（淘系的叫法为PV对，P为property，V为value）。由属性集合组成的库我们称之为属性库，由属性值集合组成的库我们称之为属性值库。
品牌库即像“nike”、“Adidas”之类的商品品牌。因为品牌和型号数据的重要性，品牌库和型号库作为两个属性值库的特例被单独拆分出来进行了维护，品牌和型号本质上也是属性的一种。政采云在16年之初，是有型号库的，后来在和阿里的运营同学进行沟通后，发现型号这类数据量庞大，且增量数据不可控，因此型号库自16年后，就不再进行维护了，而是作为一个可由供应商自由填写的属性进行管理。
政采云平台在建设初期，并没有专门的属性值库，最初的属性值是以json形式如["黑色","白色"]存储在特定列中的。之所以拆分出独立的属性值库，是为了更好的对属性值数据进行管理，避免混乱和无法维护。比如A运营在管理颜色属性的时候，其属性值域为["黑色","白色"]，B运营可能习惯为["黑","白"]。如果按此不加限制，平台的基础属性值数据将会混乱不堪，从而导致使用属性值的商品的数据的混乱，因此政采云在19年的时候单独抽离了一个属性值库并进行了痛苦的数据治理之旅。
介绍了属性和属性值，接下来要讲下平台最重要的概念类目属性。类目是分类，属性是特征，那么类目属性则代表了某个分类下的共有特征。比如所有的“卫衣”，都会有“尺码”和“颜色”这两个特征，那么“尺码”和“颜色”将会作为“卫衣”类目的两个类目属性来用于描述所有的卫衣类目的商品。类目属性的这一设计理念，一定程度上解决了类目膨胀的问题。设想如下（图一）的服装类目场景：
类目 + 类目属性 + 商品的概念和面向对象的概念是一致的，其中类目即面向对象中的类，类目属性则为类的属性，商品则为类实例化后的对象。类目 + 类目属性 + 商品是一个非常典型的设计理念，比如平台中的业务类别、业务实例的概念以及业务身份的概念都可以在一定程度上借鉴这套设计理念。
类目和属性产生关联时，因为不同的分类的特征不一样，同样的属性关联到不同类目时，其关联关系的元数据可能会产生差异，如对于颜色这一个属性，在服装类目是用户非常关心的属性，平台在运营时为了确保商品信息的完整，通常会限制此服装类目下颜色是必填，而对于想打印纸等对颜色不关心的类目，平台运营通过会设置成非必填。同理属性值也会因类目不同产生差异，如都是屏幕尺寸这一属性，手机类目和电脑类目的手机尺寸值域就完全不一样。为类目属性再去额外定义元数据是运营需要，目的在于能够更好的对供应商填写的商品数据进行管控，提高平台的商品质量，而对于一个平台来说，数据的准确性越高，平台的价值也越大。目前平台中的类目属性元数据如下所示：
| 元数据 | 含义 |
|---|---|
| 属性类型 | |
| └ 关键属性 | 唯一能确认一个产品的属性，如索尼 DSC-WX700 |
| └ 销售属性 | 影响商品价格的属性，如iphone的内存属性 |
| └ 绑定属性 | 受SPU绑定无法修改的属性 |
| └ 商品属性 | 商品除关键、销售外的普通属性 |
| └ 其他属性 | ？ |
| 必填 | 属性是否必填 |
| 可编辑 | 供应商是否可编辑此属性的值 |
| 值域 | 某类目下属性的值域，如Macbook的颜色值域仅有"白色"和"灰色" |
上述的元数据会进入到商品发布环节，随之去约束商品的某个属性的规则，如<屏幕尺寸, 14寸> 在Macbook Pro这个SPU下是绑定属性，则此属性在供应商通过SPU进行商品发布时会受到元数据的约束无法进行修改。
二、业务模型
此章节面向产品和研发，描述xx模块的业务模型结构图，依据业务背景进行的业务建模后抽象出来的简要模型。包括静态的业务结构图和动态的关键流程图
三、平台现状
此章截取平台现有的业务界面，其中截图一为平台现有的属性管理页，截图二为后台类目关联属性页。
四、业务关联
此章节面向产品和研发，罗列xx模块和平台中其他模块的业务关联关系，任何一个模块都不是孤立存在的，通过罗列业务关系可以让同学在脑海中形成平台中模块之间的关系网， 加深对此模块的理解。
关联中，必须罗列生产方、消费方。格式如下
| 业务模块 | 和xx模块的关联 |
|---|---|
| 后台类目 | 后台类目和属性关联形成类目属性 |
| 元数据中心 | 属性体系定义商品的元数据，元数据定义了平台的元数据，两者殊同同归 |
五、UML建模
此章面向技术研发，是根据前四章节的铺垫后，技术上进行技术建模抽象后的模型，包括但不限于用例图、UML类图、活动图、状态图等。
六、物理模型
此章节面向技术研发，主要罗列技术建模后对应的物理模型设计。为方便查看，建议仅列出关键字段。
[中文表名]表（英文表名）
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | 如：自增id | bigint(20) | PRI | NO | |
| 2 | code | 如：可读的code, 全局唯一(应用保证) | varchar(20) | YES | ||
[属性表]parana_properties
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | 自增id | bigint(20) unsigned | PRI | NO | |
| 2 | prop_key | 属性名 | varchar(20) | MUL | NO | |
| 3 | code | 属性code, 用于程序端识别特定的数据类别, 如brand | varchar(20) | UNI | YES | |
| 4 | business_tags_json | 业务类别 | varchar(256) | YES | ||
| 5 | composites | 组合 | varchar(100) | YES | ||
| 6 | unit | 单位 | varchar(20) | YES | ||
| 7 | value_type | 值域类型: 单选(SELECT), 多选(MULTI_SELECT), 日期(DATE), 数字(NUMBER) | varchar(20) | NO | ||
| 10 | comment | 属性说明 | varchar(500) | YES | ||
| 11 | status | 状态: -3(删除), 1 (启用/生效) 0(禁用) | tinyint(1) | MUL | NO | |
| 14 | level | 属性级别 1：平台级；2、实例级、3区划级；4、机构级 | tinyint(1) | YES | ||
| 15 | secret_desp | 暗文描述 | varchar(30) | YES | ||
| 16 | prompt | 提示文案 | varchar(30) | YES | ||
| 17 | tb_prop_id | 淘宝id | bigint(20) | MUL | YES | |
| 20 | institution | 创建机构 | varchar(255) | YES |
[属性关联属性值表]parana_property_relation，存储一个属性关联了哪些属性值
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | 主键id | bigint(20) unsigned | PRI | NO | |
| 2 | prop_id | 属性id | bigint(20) | MUL | NO | |
| 3 | prop_value_id | 属性值id | bigint(20) | MUL | NO | |
| 4 | display_order | 属性值排序 | bigint(20) | YES | ||
| 5 | business_order | 业务排序 | bigint(20) | YES | ||
| 6 | status | 状态 枚举值：-1解绑 1生效 | tinyint(1) | YES |
[属性值表]parana_property_value
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | 属性值id | bigint(20) unsigned | PRI | NO | |
| 2 | name | 属性值名称 | varchar(400) | UNI | NO | |
| 3 | level | 属性值级别 1：平台级；2、实例级、3区划级；4、机构级 | tinyint(1) | YES | ||
| 4 | status | 属性值状态 -1冻结 1(启用/生效) 0草稿 | tinyint(1) | YES | ||
| 5 | tb_value_id | 淘宝属性值 id | bigint(20) | MUL | YES | |
| 10 | institution | 创建人机构 | varchar(50) | YES | ||
| 11 | institution_id | bigint(20) | YES |
[类目属性表]parana_category_attributes
| 序号 | 名称 | 描述 | 类型 | 键 | 为空 | 默认值 |
|---|---|---|---|---|---|---|
| 1 | id | bigint(20) unsigned | PRI | NO | ||
| 2 | category_id | 类目id | int(11) | MUL | NO | |
| 3 | property_id | 属性id | bigint(20) | MUL | YES | |
| 5 | group | 所属前台分组 | varchar(20) | YES | ||
| 7 | index | 顺序编号 | bigint(20) | YES | ||
| 8 | status | 状态,1启用,-1删除 | tinyint(1) | MUL | NO | |
| 9 | attr_metas_json | json 格式存储的属性元信息 | varchar(255) | YES | ||
| 11 | attr_vals_json | json 格式存储的属性值信息 | varchar(4096) | YES | ||
| 16 | attr_val_id_json | 属性值ids | varchar(4096) | YES | ||
| 17 | config_id | db_item_standard.zcy_category_instance_config pk | bigint(20) | YES | 1 |
七、API服务
此处不列现状，列预期的设计。此处把逻辑点也列上。
八、多租户设计
不同的租户，对于类目属性的要求也可能产生差异，一种是属性元信息的差异，比如目前电商平台链接在重庆网超实例下是必填属性，而在湖南网超实例下则为非必填选项。另一种是类目属性关联的差异，如湖南网超实例下（湖南财政的要求）要求平台所有的商品都必须额外填写最高限价，其他实例则不会要求此属性的录入。针对这类业务需求，平台最初的做法是通过在前端写死的方式做的，会有if(区划 = 湖南)，则渲染最高限价这一属性的方式来实现。到了后台，有越来越多的租户产生属性级的差异，因此平台针对此问题，做到了类目属性在实例下可配置。通过配置的方式彻底解决多租户下类目属性差异的问题。未来如果政采云的业务扩展到足够多的细分行业时，会有更多的此类需求的出现。
九、其他技术文档链接
本文档内容以阐述业务以及分析业务对应的业务建模和技术建模，其他如项目结构、部署架构，非功能性设计，如性能、扩展性等，在此章节贴链接单独去维护。
十、Reference
- 无
