程序包规范<br>
OP实施的场景，每个项目有自己独立的工程，依赖上级租户工程<br>
禁止直接在父类产品/工程中修改代码,父类代码都是以JAR的形式导入到项目中<br>
系统/服务的主应用程序每个项目都是独立的，在此程序中进行代码的组装
数据模型是独立的JAR工程
以业务逻辑来拆分工程<br>
数据结构规范
改变将所有属性建立到一个表上的做法，拆分成多个小表,关联，从而构成完整的属性<br>
一般的属性（没有特殊的控制作用，仅仅用来做描述等内容)通过扩展方案实现<br>
在基表上建立四十个attribute字段
attribute25-attribute32为datetime类型
attrbute33--attribute40为numeric类型
attribute1--attribute24为varchar(100)类型
不同项目的自定义扩展表不要在父类表中直接增加，而是单独建表
mdm_item为基表
mdm_item_pcb--pcb行业扩展表
mdm_item_fastprint--兴森扩展表
所有的业务表基表或是业务对象头表，应该加上租户ID
每个表统一都加字段
who字段
created_by--创建人编码
creation_data--创建日期
created_by_name--创建人姓名
last_update_data--最近修改人
last_updated_by--最近修改人编码
last_updated_by_name--最近修改人姓名
来源字段<br>
source_code--来源类型<br>
source_id--来源ID
source_line_id--来源行ID<br>
请求字段(代表接口导入时的请求ID)<br>
request_id
request_line_id
每个表的主键应该有明确的含义，不要都用ID，物料主键就用item_id，客户主键就用customer_id
不要再加enum_delete字段
有多语言需求的基表，需要建立建立对应的多语言表
基本的数据结构与对应基表相同
增加lang_code语言编码字段
增加主键字段
建议表命名方式为：基表名_l
POJO规范
每个表有一个独立的POJO
实体表名称就是表名驼峰转名
POJO应该尽量按照“业务对象”方式来组织，比如订单头表中有一个“lines"属性记录行表，有个”attaches"属性记录附件...
如无特殊需求，不要建立VO对象，VO主要用来前后端交互，现在基本上可以用ADT来取代<br>
服务规范<br>
服务拆分标准
以计算特性（IO、CPU、内存)来拆分微服务--部署的应用<br>
以业务/逻辑来拆分服务--JAR工程<br>
