通过不同程度的「抽象」设计不同「通用」程度的管理系统

在软件的设计和研发过程中，产品经理会对业务流程和管理对象进行
接口和模型的通用性太强，会导致「MVC」中的「C-控制层」非常臃肿，致使整个软件架构严重失调。
接口和模型的通用性太弱，会导致代码没有扩展性和复用性，业务每次横向扩展都可能面临重构。

场景实战

思考： 接口和模型通用到极致是什么？
答案： 不就是 KV 模型吗！！！
如果我们想管理一所学校，我们的管理对象是所有人。
我们会想，幼儿园学生管理系统、中小学生管理系统、教师管理系统、外聘人员管理系统，既然管理的都是人，那么四个系统能不能合为一体能。
事实证明，管理系统的抽象化，会随着业务系统功能的不断增加而崩塌，变得不得不增加有具体业务属性的表；同时，也会面临数据量暴增后的数据库性能问题。
我称之为，产品抽象之深渊…
因此，对于这种抽象化的设计模式，我的建议是，适用于类型多变或动态增加、上层业务逻辑简单、实体数据量小的场景。

一个管理系统的抽象复杂等级

一、不抽象：设计的表结构、直接用来使用或展示

例如，校园管理系统中，需要一个学生基本信息表来保存和管理学生的基本信息。

-- 1. 学生基本信息表
create table student_info(
  name varchar(100) comment '姓名',
  gender int comment '性别',
  class int comment '班级',
  grand int comment '年纪'
) comment '学生基本信息表';

二、一级抽象：属性可配置、可录入、可展示

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。

-- 1. 人员信息表，每一个人对应一条信息
create table person_info(
	person_id int comment '人员ID',
	card_type int comment '证件类型',
	card_num varchar(100) comment '证件编号',
	category_id  int comment '人员的分类ID'
)  comment '人员信息';
-- 2. 人员的属性信息，每一人的属性，例如学生，会有（姓名、性别、班级、年纪）4条属性的值
create table person_info_value(
	person_id int comment '人员ID',
	category_id  int comment '人员的分类ID'
	attr_id int comment '属性ID',
	attr_value varchar(100)  comment '属性值'
)  comment '人员属性值信息';
-- 3. 人员分类信息，例如学生、教师、保安等，每一种分类对应一条数据
create table person_category(
	category_id int comment '分类ID',
  category_name varchar(100) comment '分类名称，例如：学生、教师、保安等'
) comment '人员分类信息';
-- 4. 人员分类的属性定义，一条属性对应一条数据，例如学生类型，会有（姓名、性别、班级、年纪）4条属性
create table person_attr(
	attr_id int comment '属性ID',
	category_id int comment '属性所属的分类ID',
	attr_name varchar(100) comment '属性的名称，例如：姓名、性别、班级、年纪等',
	attr_data_type varchar(100) comment '属性值的类型，例如：INT、STRING、NUMBER等',
	use_zone int commet '属性的使用域：展示方式、是否可编辑等'
) comment '人员分类的属性定义';

三、二级抽象：定义属性的值域

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。同时，某些人员类型的属性是有值域限制的。例如，[性别]属性的取值必须在（男、女、其他性别、未提供）范围内。

-- 继承[一级抽象]的表结构
-- 5. 属性扩展信息表，存储属性的阈值
create table person_attr_ext(
	ext_attr_id int comment '扩展属性ID',
	attr_id int comment '属性ID',
	ext_value varchar(100) comment '值域的具体值'
) comment '扩展属性定义';

四、三级抽象【应用层】：属性的[值域]需要映射到具体的应用场景

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。同时，某些人员类型的属性是有值域限制的，并且要实现收费和计费的功能。例如，[入学方式]属性的取值必须在（走读、住校）范围内，并且[入学方式]中<走读>和<住校>分别对应不同的缴费清单。

-- 继承[二级抽象]的表结构
-- 6. 属性扩展信息表，存储属性的阈值、阈值的单位、阈值的适用域等
create table person_fee_list(
	ext_attr_id int comment '扩展属性ID',
	fee_name varchar(100) comment '收费项目名称，例如：课本费、补课费、住宿费、伙食费、校服费等',
	fee_value int comment '收费单价'
) comment '扩展属性定义';

五、四级抽象：类型支持可筛选

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工、行政员工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。同时，要支持校区（例如东、西、南、北四个校区）的配置和筛选，其中每个学生对应一个校区，每个教师可能对应多个校区，行政员工不属于任何校区。

-- 继承[三级抽象]的表结构
-- 7. 人员类型扩展信息，用于标记不同的类型，方便筛选使用
create table person_category_ext(
	category_id int comment '分类ID',
	ext_name varchar(100) comment '分类扩展属性名称：例如校区等',
	ext_value varchar(100) comment '分类扩展属性名称值：例如东校区、西校区、南校区等',
) comment '人员类型扩展信息';

六、五级抽象【应用层】：实体的扩展

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工、行政员工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。同时，需要支持对学生的亲属信息进行管理，例如亲属的联系方式、联系优先级、是否监护人、社会关系等。

-- 继承[四级抽象]的表结构
-- 8. 人员属性值扩展表
create table student_relate (
	person_id int comment '人员ID',
	relate_id int comment '亲属编号ID',
	relate_name varchar(100) comment '亲属的姓名',
	relate_type varchar(100) comment '与亲属的关系',
) comment '人员属性值的扩展值';

七、六级抽象【应用层】：管理不同类型人员建的关系

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工、行政员工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。同时，还要管理具体学生和老师之间的关系。

-- 继承[五级抽象]的表结构
-- 9. 师生关系表，实体间的关系，肯定有业务属性和具体业务场景【可以用这个方案解决五级抽象中的问题】
createt table student_teacher_relate(
	student_id int comment '学生id',
	teacher_id int comment '教师id'
) comment '师生关系表';

八、七级抽象：通过标签管理不同类型的属性的关系

例如，有一个非常复杂的校园管理系统，需要把中学生、小学生、幼儿园学生、教职工、非教职工、行政员工等人员信息，统一管理起来，并且有可能有新增的人员类型，要支持动态配置。同时，希望对有相同属性的的人员进行统一的管理，例如教师和行政员工都是学校只聘的员工，都有一个薪资的属性，需要支持发工资的功能。

-- 继承[六级抽象]的表结构
-- 10. 标签管理。自定义实体标签，指的是通过手动打标签，给具体的某个人员标记一个标签；属性标签指的是，某个属性代表了一个标签。
create table person_label(
	label_id int comment '标签ID',
	lable_name varchar(100) comment '标签的名称',
	lable_comment varchar(100) comment '标签的描述',
	lable_type int comment '标签的类型：自定义实体标签；属性标签',
	lable_value int comment '如果是属性标签，是否有值域'
) comment '标签管理表';
-- 11. 标签值域表
create table person_label_ext(
	label_id  int comment '标签ID',
	label_value varchar(100) comment '标签的值域'
) comment '标签值域表';
-- 12. 实体标签关联表，关联标签和具体人员，是多对多关系
create table person_label_relate(
	person_id int comment '人员ID',
	label_id int comment '标签ID'
) comment '实体标签关联表';
-- 13. 属性标签关联表，关联标签和某个属性，是一对多关系，一个属性最多属于一个标签；一个属性被绑定到一个标签时，则继承这个标签的值域
create table person_label_relate(
	attr_id int comment '属性ID',
	person_id int comment '人员ID',
	label_id int comment '标签ID'
) comment '实体标签关联表';

达到第七级别后，整体架构如下图所示：

1、第一、第二层的复杂程度，是对管理对象的基本抽象，用圆形表示；

2、第四、第七层的复杂程度，属于对属性和实体的分类和筛选，用椭圆表示；

3、第三、第五、第六层的复杂程度，属于对具体业务功能的支持，用方形表示；