OMS工程规范
2024-08-23 11:42:21 1 举报AI智能生成
工程开发规则
作者其他创作
大纲/内容
OP实施的场景，每个项目有自己独立的工程，依赖上级租户工程
系统/服务的主应用程序每个项目都是独立的，在此程序中进行代码的组装
数据模型是独立的JAR工程
以业务逻辑来拆分工程
程序包规范
主键
扩展信息
建立JONS格式的扩展表
attribute25-attribute32为datetime类型
attrbute33--attribute40为numeric类型
attribute1--attribute24为varchar(100)类型
在基表上建立四十个attribute字段
一般的属性（没有特殊的控制作用，仅仅用来做描述等内容)通过扩展方案实现
mdm_item为基表
mdm_item_pcb--pcb行业扩展表
mdm_item_fastprint--兴森扩展表
不同项目的自定义扩展表不要在父类表中直接增加，而是单独建表
所有的业务表基表或是业务对象头表，应该加上租户ID
created_by--创建人编码
creation_data--创建日期
created_by_name--创建人姓名
last_update_data--最近修改人
last_updated_by--最近修改人编码
last_updated_by_name--最近修改人姓名
who字段
source_code--来源类型
source_id--来源ID
source_line_id--来源行ID
来源字段
request_id
request_line_id
请求字段(代表接口导入时的请求ID)
每个表统一都加字段
每个表的主键应该有明确的含义，不要都用ID，物料主键就用item_id，客户主键就用customer_id
不要再加enum_delete字段
基本的数据结构与对应基表相同
增加lang_code语言编码字段
增加主键字段
建议表命名方式为：基表名_l
有多语言需求的基表，需要建立建立对应的多语言表
数据结构规范
每个表有一个独立的POJO
实体表名称就是表名驼峰转名
POJO应该尽量按照“业务对象”方式来组织，比如订单头表中有一个“lines\"属性记录行表，有个”attaches\"属性记录附件...
如无特殊需求，不要建立VO对象，VO主要用来前后端交互，现在基本上可以用ADT来取代
POJO规范
以计算特性（IO、CPU、内存)来拆分微服务--部署的应用
以业务/逻辑来拆分服务--JAR工程
服务拆分标准
服务规范
一般的情况下，不用单独开查询接口
查询接口规范
ETL==>ELT
串行队列式更新
接口数据暂存
内外部接口规范
OMS开发规范
0 条评论
回复 删除
下一页
