22｜泛化建模（上）：领域知识更抽象怎么办？
2023-01-31 钟敬
《手把手教你落地 DDD》
课程介绍
讲述：钟敬
时长:大小11.93M
你好，我是钟敬。
上节课，我们学习了“限定”技术。利用这个技术可以丰富模型的语义并简化关联。今天，我们要挑战领域建模中的另一个话题——泛化。
泛化是领域建模技能由初级水平迈向中、高级水平的门槛。也就是说，如果不懂泛化，那么你的领域建模水平就始终停留在中级以下。初步掌握了泛化，那么你的水平可能就能达到中级。把泛化玩得出神入化，那么大概就能达到高级水平了。
领域建模层面的泛化，大体上相当于面向对象设计中的继承和多态。如果你学习过“设计模式”的话，还记得刚开始的“痛苦”吗？其实，整本《设计模式》，无非是教你怎么灵活运用多态罢了。而在领域建模层面，与《设计模式》对应的就是《分析模式》。整本《分析模式》也无非是教你怎么成为使用泛化的高手。
我们现在要讲的内容，尽管达不到“分析模式”的高度，但是可以为你将来的学习打下基础，帮你在实际工作中解决一些相对复杂的问题了。
我安排了 5 节课的时间，带你分别由泛化的建模、泛化的数据库设计以及泛化的代码实现由浅入深地认识和理解泛化。
这节课会围绕着“在子项目上报工时”这个需求来展开讨...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
子衿2023-01-31 来自浙江1. 因为学习时间和管理时间，只有共性没有个性部分，所以不必泛化作者回复: 这个理由也说得通
10
阿昕2023-02-08 来自浙江思考题，学习时间和管理时间虽然也可以进行分类，但是两者已经是原子属性了，没有必要进行抽象，所以不构成泛化关系作者回复: 是的
9- Geek_66158e2023-02-23 来自浙江问题一：因为从报工时的角度来看，已经不再关心普通工时项下的“个性”了，普通工时项这种“共性”对于报工时来说已经有意义的最小的粒度了。
作者回复: 这个角度很棒
7 
6点无痛早起学习的和...2023-02-15 来自北京思考题 2：想到一个实际上的场景，但是拿捏不定是不是泛化 父类：账户项 子类：现金账户、备付金账户、待清算账户等等 每个账户项都有余额属性：可用余额、冻结余额作者回复: 您列出了共性，但没有列出个性。如果有个性（不同的属性，不同的算法等），可以考虑用泛化，否则就不要用泛化了。
4
赵晏龙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
刘毅2023-12-21 来自上海钟老师您好，结合您前面讲的第5节中组织与组织类别的抽象过程以及java面向对象思想，我的理解如下，不知道是否正确。 值对象（个性）->实体（共性）与子实体（个性）->父实体（共性）两种机制都能够同时表现出不同实体间的共性和个性，两者主要的区别是个性部分在当前业务领域内是否复杂。 若个性部分在当前业务领域内比较复杂（具有自己的标识、属性或方法等），则可用子实体实现；若个性部分在当前业务领域中比较简单（如只是简单划分几个枚举值），则可用值对象实现。作者回复: 是的
共 2 条评论
Geek15602023-10-26 来自上海工时项作为项目和子项目的泛化有点怪怪的，仅仅因为它们有个很小的相同点是工时就做这种抽象是不是不太合适？项目和子项目的大部分信息应该都是相同的，而不仅仅是工时作者回复: 项目和子项目作为工时项的共性，对于登记工时而言，是重要的。是否“很小”取决于主观的权衡。项目和子项目抽出更多的共性也是可以的，关键看用在哪里。有用就抽，否则没必要仅仅因为相似而抽。