24 | 实战一（下）：如何实现一个遵从设计原则的积分兑换系统？
该思维导图由 AI 生成，仅供参考
业务开发包括哪些工作？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何实现一个积分兑换系统的代码实现。首先讲解了业务开发包括接口设计、数据库设计和业务模型设计三方面的工作。接着详细讨论了数据库设计和接口设计的重要性，以及业务模型的设计原则。作者强调了分层开发的重要性，分别从代码复用、隔离变化、隔离关注点、可测试性和应对系统复杂性等方面进行了解释。最后，作者建议将积分系统作为一个独立的项目进行开发，同时强调了模块化和解耦的重要性。整体而言，本文通过讲解积分系统的代码实现和分层开发原则，为读者提供了一些普适的开发思想和设计原则。 在文章中，作者提到了分层开发的重要性，包括代码复用、隔离变化、隔离关注点、可测试性和应对系统复杂性等方面的解释。此外，还介绍了VO、BO、Entity的设计思路，以及如何解决代码重复的问题。同时，文章还涉及了数据对象之间的转化和设计原则和思想的应用。读者可以从中学习到如何进行业务开发、数据库设计和接口设计，以及分层开发原则的重要性。
《设计模式之美》，新⼈⾸单¥98
全部留言(139)
- 最新
- 精选
李朝辉课堂讨论1: 业务驱动的系统还是应该从业务的角度出发去做设计，这两个字段在积分明细查询中是不可或缺的，所以我认为是合理的。既然是不可或缺的，如果不记录在这张表中，就要记录在其他表中，或者查询不便，或者破坏内聚。 2.根据个人经验，insert操作的都是返回记录id，原因的个人观点是为调用方提供便利。还请老师解答作者回复: 说的挺对的
2019-12-27280
杨杰个人感觉：VO、BO、Entity 通过组合关系来复用这个类的代码不是特别好，尤其是VO。因为用组合的方式会增加返回数据的层次，这对前端来说是不是不不太友好？作者回复: 是的 主要是对象转json的格式问题
2019-12-27441
辣么大反馈一个文章朗读的小问题：音频3:00左右 facade设计模式 应该读做/fə'sɑ:d/ ，冯老师读的不是很准确。 ”吹毛求疵“，希望专栏做的更专业。编辑回复: 应该吹毛求疵，我们fix去
2019-12-27736
斐波那契老师 beanutils会不会性能不好 毕竟大量用到了反射 有没有代码不那么繁琐性能也比较好的方法作者回复: 对于大部分业务系统来说 数据库是最耗时的 对象转化那点性能损失可以忽略
2019-12-311221
黄林晴打卡✔ 难道是我膨胀了，实战的内容没有理论看的起劲作者回复: 期望太高了 也不可能篇篇让你高潮
2019-12-27615- 胖子我有一个疑问：接口设计、数据库设计和业务模型设计如何对应或过渡到MVC分层？
作者回复: 接口 controller层 数据库 repository 业务 service
2019-12-279 
杨陆伟
VO、BO、Entity频繁的克隆、拷贝会不会引入性能问题，这点是怎么考虑的？谢谢作者回复: 虽然有性能损耗 但可以忽略 影响不大
2020-01-0286
永旭3层架构 和 MVC 不是 2中概念吗 ? 3层架构: 表示层, 业务层 , 数据访问层 MVC: model , view , controller 3层架构.表示层 = MVC.controller + MVC.view ??作者回复: 表示层=view层吧 ，不过，现在后端的这种controller+service+repo 已经不能完全对应到mvc三层了
2020-07-1025- YsnowLove这篇文章是实战篇，为啥没有说明积分余额的设计，作为一个用户，首先关心的是积分余额吧。不可能每次看积分余额都要查询所以积分明细，然后计算一遍。
作者回复: 增加一个总余额，就要维护数据的一致性了。就变得复杂了。而计算余额并非太复杂。当然，如果积分表中的数据量很大，那增加余额也是可以的。这个具体来看，没有说非得选择哪个设计更好。
2020-06-225 - 林为什么积分明细表没有user_id字段，如何查询用户的可用积分
作者回复: 是个问题 我改下
2020-01-024
