【经验感悟】总结系统设计中遇到的困惑
在维护以前老旧代码的过程中，发现很多需要优化、再设计的地方，但奈何系统已经成型，并且稳定运行，再设计的代价非常的高，基本是不现实的。于是，我开始想，如果重新设计，要该怎么去做。然后思来想去，并没有一个标准答案。（可能我书还是看的少了）
下面记录几个困惑的地方。
1.领域实体模型的属性的增加和删除如何处理
1.1 增加一项属性
比如，在员工薪资管理系统，员工是个领域实体模型。员工模型有个属性是学历（也可用其它用户可自定义的属性举例），在录入员工信息时，需要选择该员工的学历。因为学历是比较常见的：大专、本科、硕士、博士，系统开发的早期学历被硬编码为这么几个也没有什么问题。但后期的时候突然要求增加：高中/中专、博士后，那怎么办呢？
- 修改硬编码的代码，继续增加学历，硬编码。
- 把学历单独做个数据库表，然后交由用户去增加删除
- 把学历存储在配置文件中
1. 这个对于学历这种不常变化的，可以这样做。但如果较频繁一点，令人头疼。
2. 这个感觉太笨重，学历只是一个并不核心的业务信息，单独做表，就两个字段做个表，然后再做增删，性价比不高。
3. 没有尝试过。但有个问题就是配置文件的某项的更新和删除操作会引起下面1.2 和 1.3 的问题。
1.2 删除一项属性
其实，相对于 增加 这种可以硬编码的小问题，删除才是令我困惑的。
假设，学历内容是存储在数据库表中，1对应大专、2对应本科、3对应硕士、4对应博士。职工张三的学历是<1，大专>，突然有一天，系统调整，需要去除“大专”学历（我们举例而已），那么系统如何做更改？
- 真删除学历表中该项记录，那么张三的学历信息就彻底的丢了。这如果不是学历，是重要的业务信息，岂不惨了。
- 假删除，录入新员工信息时，大专选项确实没有了。但我们查询历史数据时，张三的学历一栏该显示什么呢？只显示个 1 么。学历信息岂不是也丢了。
1.3 更新一项属性
更新和删除，问题是一样的。
将<1，大专>记录更新为<1，博士后>，这肯定乱套了。按道理，是不能更新为其它不同含义的。
2.领域实体模型的类型属性
同样的，员工有个属性是英语等级，CET4和CET6，擅长语言有英语、德语、俄语，这些属性值到底是该怎么保存。肯定不能硬编码，写死在代码里。但是单独为英语等级、擅长语言建个一个又一个表，也太费事了。
3.管理信息的角色与权限
在系统构建早期，我们都认为 角色是权限的集合，在系统体现出来就是，每个用户可勾选多个角色，每个角色可勾选多个权限，每个权限控制一些菜单和按钮。
然后，当系统中出现“流程控制类”的功能（如公文流转）时，流程控制中也出现了个“角色”，而这个“角色”却和原来的角色不同。新的角色，和系统权限并不挂钩，而是在小小的流程控制模块中发挥着“身份”的作用。
比如项目组长的身份，项目总监的身份，各代表着一定的收发公文、转派公文、签收公文、审核签字的功能，显然与系统中的“系统管理员”、“部门管理员”等角色含义大不相同。但在我们的系统中却混为一谈，把单个模块中的“角色”也当作系统“角色”统一放在了一个数据表中，一起进行维护，结果就是混乱！
如果能重新设计，我觉得“流程控制”类的功能里面的“身份”应单独抽象建表，作为该子模块的“角色”表，而不要和系统级别的“角色”概念混用。这样二者都可赋予给用户，系统角色不代表流程控制里的身份。
4.不同Web系统之间的数据同步
这才是最头疼的大问题。
如果在不同的Web系统之间同步数据，我只了解到有 WebService，但WebService非常依赖对方，对方服务一旦宕机，数据传输就断了。也不能实时的传输大量数据。
就先记录这些吧。
