阿昕2023-02-08 来自浙江思考题，学习时间和管理时间虽然也可以进行分类，但是两者已经是原子属性了，没有必要进行抽象，所以不构成泛化关系作者回复: 是的
9
子衿2023-01-31 来自浙江1. 因为学习时间和管理时间，只有共性没有个性部分，所以不必泛化作者回复: 这个理由也说得通
9- Geek_66158e2023-02-23 来自浙江问题一：因为从报工时的角度来看，已经不再关心普通工时项下的“个性”了，普通工时项这种“共性”对于报工时来说已经有意义的最小的粒度了。
作者回复: 这个角度很棒
4 
请叫我和尚
2023-02-15 来自北京思考题 2：想到一个实际上的场景，但是拿捏不定是不是泛化 父类：账户项 子类：现金账户、备付金账户、待清算账户等等 每个账户项都有余额属性：可用余额、冻结余额作者回复: 您列出了共性，但没有列出个性。如果有个性（不同的属性，不同的算法等），可以考虑用泛化，否则就不要用泛化了。
3
赵晏龙2023-02-14 来自湖南老师你的总结是想引发粽子战争吗？ 1. 粽子……不是，学习时间和管理时间在业务需求上没有需要泛化的必要，泛化则变成了过度设计。 2. 我现在满脑子粽子，等我缓缓作者回复: 幸亏没引起豆腐脑战争
共 2 条评论1
aoe2023-02-01 来自浙江思考题 1. 「学习时间」和「管理时间」所有属性都相同，添加一个新属性「类型」就可以进行区分 2. 封装第三方登录（微信、手机号、QQ）；封装第三方支付（支付宝、微信、银联）；封装不同等级用户提现时的手续费计算逻辑 其他想法 1.「工时记录」中需要新加一个属性「类别」，这样方便以后按类别查找记录（由泛化引发的一个坑） 2. 今天刚好读到《DDD》第 9 章，趁热打铁，又多理解了一点 3. 感觉「泛化」就像代码中的「接口」。写代码时「面向抽象编程」，建模时「面向抽象建模」。当一个程序员，不会「抽象」还真吃力啊！ 4. 「直接“借用”系统中已经存在的机制，在短期内虽然达到了目的，但长期来看会导致概念混乱，这种做法是很多开发团队常见的错误」这是我们项目中的常态，开发一时爽，后来很多人走了…… 5. 明白了 Predicate（谓词/谓语） 在编程中的意思：谓词是指计算结果为「真」或「假」的函数，并且可以使用操作符（如 AND 和 OR）把它们连接起来以表达更复杂的规则。 —— 《领域驱动设计 软件核心复杂性应对之道》9.2.3 模式： SPECIFICATION 钟老师还提到了一本书：《离散数学》，里面的一阶谓词理论，就是说这个展开作者回复: 没毛病，继续努力！
1
Michael2023-01-31 来自陕西期待老师讲泛化的数据库设计和代码实现，有些时候我在做项目的时候也觉得应该有泛化，但是只体现在模型设计上，但是不懂怎么体现在数据库设计和代码实现上，导致很多想法就此打住。编辑回复: 泛化实现已经更新了，可以去看啦！
共 2 条评论1
小52023-01-31 来自广东回答问题1：因为两者有共性但是没有业务上关注的差异性作者回复: 是这么个意思
1- Geek_4e4ec22023-03-30 来自云南有个问题，将工时项移到工时管理后，项目实体岂不是要继承或实现工时项，但它们是在两个上下文里，相当于一个上下文里直接引用了另一个上下文中的领域对象，这样也没问题？
作者回复: 到这节课为止，还没有分上下文（只分类模块），所以不成问题。在第三个迭代分上下文以后（29课），会把这个问题解决掉。
Y024
2023-02-17 来自福建“学习时间”和“管理时间”，我们是作为一个灵活工时项目来处理。作者回复: 可以这么理解。两者之间除了名字不同，没有其他个性了。