设计规范
# 设计目的
设计文档的作用是明确需求、理顺逻辑、后期维护，次要目的用于指导编码。
设计的本质就是识别和表达系统难点。
系统架构设计时明确以下目标
确定系统边界。确定系统在技术层面上的做与不做。
确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。
确定指导后续设计与演化的原则。使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化
确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。
# 表设计
- 建表规范
a，表名，字段命名以下划线分隔，表名，字段名必须使用小写字母，不能出现大写字母，禁止数字开头。禁止两个下划线之前出现数字
b，表名及字段名注释要完整可读
c，表必备字段 id (主键) add_cust_id （添加企业） oper_cust_id （修改企业） add_user_id （添加人） oper_user_id （修改人） add_time （添加时间）oper_time （修改时间） alive_flag（状态值），业务关联表除外
d，索引命名规范：主键索引，PK_字段名。唯一索引，UK_字段名。普通索引，IDX_字段名
e，建表前，需考虑该业务的数据量，唯一值以及相关查询条件，合理添加相关索引。
f，字段适当冗余，来保证查询的性能。建议冗余字段 1，不是频繁改动的字段 2，不是超长的varchar或者是text
g，如果出现修改字段含义或状态值追加，需及时更新表字段注释
# 业务设计
# 设计原则
在经过表结构设计完成后，模块和模块间的数据结构和数据交互通过表结构或ER图已基本形成，接下来需要对模版内部的实现细节做进一步填充。根据抽象思维，每个模块基本上是由增删改查四个动作组成。可再次抽象为，查询类动作和操作类动作。针对查询类和操作类动作需要从以下维度思考或定义内部实现。
# 查询动作从以下步骤定义顺序:
- 1，校验：查询入参需定义，包括查询条件，排序条件，分页条件，返回结果集等。
- 2，校验：入参校验，包括入参非空校验，入参类型校验，入参范围校验，入参格式校验，入参关联校验等。
- 3，查询：关联业务的查询信息获取，例如品牌管理，品牌关联了分类关系表, 根据分类信息关联查询品牌主键，再根据品牌主键查询品牌信息。
- 4，操作：当前业务的DB查询。
- 5，返回：返回结果集封装。会包含从其他业务表关联查询进行返回信息组装。
# 操作动作从以下步骤定义顺序:
- 1，校验：表单入参校验，包括表单非空校验，表单类型校验，表单范围校验，表单格式校验，表单关联校验等。
- 2，校验：表单字段的业务关联校验或业务状态校验，比如已审核的不能再次提交。
- 3，封装：操作model的信息封装并包含了关联业务的获取关键信息的封装。
- 4，操作：当前业务的DB操作。
- 5，回调返回：当前业务操作完是否需要通知其他业务，比如通知其他业务更新数据等。
- 6，返回：返回结果集封装。
# 设计要求
- 模块设计中流程图及思维导图需涵盖，流程图能够标记本模块的生命周期，思维导图则规划出该模块的具体功能点 如下图：
模块设计过程中需定义好模块接口，以面向接口编程的思想。接口一旦定义完成，除非特殊场景，一律不准修改接口类型及入参
模块设计中，需了解数据性能问题，数据量过大采用读写分离，分库分表及缓存策略。缓存数据需考虑二八原则
模块设计过程中，解耦方案同服务优先考虑设计模式，跨服务则使用Topic
模块设计过程中，考虑公用性，处理多场景的Insert的操作，使用函数式接口对接口进行二次封装
模块设计过程中，如果系统中超过 2 个对象之间存在协作关系，并且需要表示复杂的处理流程，使用活动图来表示
模块设计过程中，如果系统中模型类超过 5 个，并且存在复杂的依赖关系，使用类图来表达并且明确类之间的关系。
模块设计过程中，如果系统中某个功能的调用链路上的涉及对象超过 3 个，使用时序图来表达并且明确各调用环节的输入与输出。
模块设计过程中，如果某个业务对象的状态超过 3 个，使用状态图来表达并且明确状态变化的各个触发条件。
# 注意事项
a，系统设计阶段，共性业务或公共行为抽取出来公共模块、公共配置、公共类、公共方法等，在系统中不出现重复代码的情况 （随着代码的重复次数不断增加，维护成本指数级上升）
b，系统设计阶段，注意对扩展开放，对修改闭合
c，需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。
单一业务模块提供基础的的添加，修改，删除，详情，列表，分页列表外，如有关联其他业务查询附加信息，另行定义接口。禁止在基础接口里面添加其他业务附加信息