22｜泛化建模（上）：领域知识更抽象怎么办？

思考题，学习时间和管理时间虽然也可以进行分类，但是两者已经是原子属性了，没有必要进行抽象，所以不构成泛化关系

1. 因为学习时间和管理时间，只有共性没有个性部分，所以不必泛化

问题一：因为从报工时的角度来看，已经不再关心普通工时项下的“个性”了，普通工时项这种“共性”对于报工时来说已经有意义的最小的粒度了。

思考题 2：想到一个实际上的场景，但是拿捏不定是不是泛化 父类：账户项 子类：现金账户、备付金账户、待清算账户等等 每个账户项都有余额属性：可用余额、冻结余额

老师你的总结是想引发粽子战争吗？ 1. 粽子……不是，学习时间和管理时间在业务需求上没有需要泛化的必要，泛化则变成了过度设计。 2. 我现在满脑子粽子，等我缓缓

思考题 1. 「学习时间」和「管理时间」所有属性都相同，添加一个新属性「类型」就可以进行区分 2. 封装第三方登录（微信、手机号、QQ）；封装第三方支付（支付宝、微信、银联）；封装不同等级用户提现时的手续费计算逻辑 其他想法 1.「工时记录」中需要新加一个属性「类别」，这样方便以后按类别查找记录（由泛化引发的一个坑） 2. 今天刚好读到《DDD》第 9 章，趁热打铁，又多理解了一点 3. 感觉「泛化」就像代码中的「接口」。写代码时「面向抽象编程」，建模时「面向抽象建模」。当一个程序员，不会「抽象」还真吃力啊！ 4. 「直接“借用”系统中已经存在的机制，在短期内虽然达到了目的，但长期来看会导致概念混乱，这种做法是很多开发团队常见的错误」这是我们项目中的常态，开发一时爽，后来很多人走了…… 5. 明白了 Predicate（谓词/谓语） 在编程中的意思：谓词是指计算结果为「真」或「假」的函数，并且可以使用操作符（如 AND 和 OR）把它们连接起来以表达更复杂的规则。 —— 《领域驱动设计 软件核心复杂性应对之道》9.2.3 模式： SPECIFICATION 钟老师还提到了一本书：《离散数学》，里面的一阶谓词理论，就是说这个

期待老师讲泛化的数据库设计和代码实现，有些时候我在做项目的时候也觉得应该有泛化，但是只体现在模型设计上，但是不懂怎么体现在数据库设计和代码实现上，导致很多想法就此打住。

回答问题1：因为两者有共性但是没有业务上关注的差异性

钟老师您好，结合您前面讲的第5节中组织与组织类别的抽象过程以及java面向对象思想，我的理解如下，不知道是否正确。 值对象（个性）->实体（共性）与子实体（个性）->父实体（共性）两种机制都能够同时表现出不同实体间的共性和个性，两者主要的区别是个性部分在当前业务领域内是否复杂。 若个性部分在当前业务领域内比较复杂（具有自己的标识、属性或方法等），则可用子实体实现；若个性部分在当前业务领域中比较简单（如只是简单划分几个枚举值），则可用值对象实现。

工时项作为项目和子项目的泛化有点怪怪的，仅仅因为它们有个很小的相同点是工时就做这种抽象是不是不太合适？项目和子项目的大部分信息应该都是相同的，而不仅仅是工时