设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
18290 人已学习
课程目录
已更新 27 讲 / 共 100 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (10讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册

24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?

王争 2019-12-27
上一节课中,我们讲了积分系统的需求分析和系统设计。今天,我们来讲它的代码实现。
上一节课中,我们把积分赚取和消费的渠道和规则的管理维护工作,划分到了上层系统中,所以,积分系统的功能变得非常简单。相应地,代码实现也比较简单。如果你有一定的项目开发经验,那实现这样一个系统,对你来说并不是件难事。
所以,我们今天讲解的重点,并不是教你如何来实现积分系统的每个功能、每个接口,更不是教你如何编写 SQL 语句来增删改查数据,而是给你展示一些更普适的开发思想。比如,为什么要分 MVC 三层来开发?为什么要针对每层定义不同的数据对象?最后,我还会总结这其中都蕴含哪些设计原则和思想,让你知其然知其所以然,做到真正地透彻理解。
话不多说,让我们正式开始今天的学习吧!

业务开发包括哪些工作?

实际上,我们平时做业务系统的设计与开发,无外乎有这样三方面的工作要做:接口设计、数据库设计和业务模型设计(也就是业务逻辑)。
数据库和接口的设计非常重要,一旦设计好并投入使用之后,这两部分都不能轻易改动。改动数据库表结构,需要涉及数据的迁移和适配;改动接口,需要推动接口的使用者作相应的代码修改。这两种情况,即便是微小的改动,执行起来都会非常麻烦。因此,我们在设计接口和数据库的时候,一定要多花点心思和时间,切不可过于随意。相反,业务逻辑代码侧重内部实现,不涉及被外部依赖的接口,也不包含持久化的数据,所以对改动的容忍性更大。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(21)

  • 桂城老托尼
    感谢争哥分享。
    个人觉得积分系统只有流水记录不太够,设想下消费积分场景,要完成扣积分的动作,没有积分余额表容易造成多扣,特别是针对羊毛党。当然上层系统,比如活动系统也可以做好幂等。
    尝试回答下课后讨论
    1. 保留上层应用id和channel完全符合设计原理,冗余业务信息方便日后做数据统计,沉淀数据资产反推营销策略迭代; 一次消费或赚取积分行为可能存在多次调用情况,方便幂等,不至于多次记账;方便业务系统查询某次赚取或消费的积分明细;暂时想到这么多。
    2. 尽量不要返回void或boolean,有些业务需要反向关键积分流水id做单笔流水查询。
    其实这两个讨论都类似于现实生活,去便利店买东西会给你小票,支付宝扫码付款会返回交易流水。都是为了方便真是场景解决“纠纷”(查询)用的。
    2019-12-27
    2
    5
  • 辣么大
    针对争哥的第一个问题,从设计角度来说不应该记录渠道和事件。从业务来说,必须记录交易的渠道和事件。基于这种妥协可以设计一张表。那是否也可以设计两张表?

    积分交易表和明细表:
    1、credit_transaction
    trans_id
    user_id
    channel_id
    event_id
    create_time
    2、积分明细表credit_detail,只记录积分加减
    trans_id
    credit (积分加减)
    create_time
    expire_time
    2019-12-27
    10
    3
  • 黄林晴
    打卡✔
    难道是我膨胀了,实战的内容没有理论看的起劲
    2019-12-27
    3
  • aya
    1增加上层相关字段有利于出现问题时的排查工作,并且ods等系统在抽数据时也可以提供完整数据。
    2不违背单一指责原则,赚取积分和消费积分的业务逻辑必然会伴随积分余额查询,业务上应属同一逻辑,拆分反而shi程序复杂。
    2019-12-27
    3
  • Jeff.Smile
    实际中没见过同时定义vo bo entity的
    2019-12-27
    2
  • 下雨天
    说说第一个问题,系统设计跟数据库设计没必然联系,这样设计合理!
    数据库设计中有点像服务器请求设计
    1.数据库拆分过细,各表字段间关联变麻烦了,提高数据不一致性风险!
    2.数据库中表多意味着访问可能性变大,数据库的连接,建立都是需要时间和消耗性能的!
    2019-12-27
    2
  • Jxin
    1.不符合一对上下游系统的设计要求,但适合当下业务场景的需求。 下游积分核心系统设计上不该持有事件和渠道字段,因为它不该去关心上游业务,事件或渠道与对应积分明细的关联应该由上游系统来维护,或则在上游系统和积分系统之间再加一层积分系统的业务层,用于维护这层关系(关于易复用性的中台思想)。当下的业务场景,积分的管理系统是有必要维护一份 事件渠道的值对象的。因为带有这个值对象,积分系统管理员才能不需要再多个系统中寻找积分增减关系,进而可以独立满足管理积分这件事的整个业务域。(事件和渠道只能作为值对象冗余在积分系统)。

    2.不符合单一职责的限制,但满足当前业务场景的诉求。该接口做了增减积分和返回积分id两件事,且语义上并没有返回积分id的相关字眼,所以方法名定义也不明确。但是上游系统在变更积分后,需要获取积分id以作为上游系统变更事件与积分记录的关联key。而这个key只有在当前变更操作获得,所以就只能写这种语义不明且违反单一职责的方法。(让我来设计,我会把积分id的生成作为积分系统的一个外放接口,上游业务调用该接口获取id,记录关联关系,然后走mq推积分系统实现最终扣减。这样就可以规避上述这种无奈的场景)。
    2019-12-27
    1
  • 知行合一
    争哥给出的是一个基础的积分系统案例,主要是从设计的角度来分析我们用到哪些原则和模式。真实场景的话肯定需要考虑高并发和大数据量的问题,那样的话可能需要单独出来积分账户表,存储积分余额,明细表需要分库分表。
    针对问题一,我觉的很有必要,毕竟业务需要查询积分的来源和做幂等性检验。
    问题二,这个主要看业务系统是否需要,大部分情况下我觉得是不需要的,业务系统增加积分或者消费积分就成了。需要的话也是为了对账,我哪个动作增加的哪笔积分,对账意义大于业务意义。
    2019-12-27
    1
  • 李小四
    设计模式_24
    # 作业
    1. 下层系统中包含了上层系统的event_id, channel_id, 这个显然是包含了(不该有的)上层信息,这样的坏处是,上层如果需要增加信息,底层的数据库要跟着改动。
    当然,这么做的原因与本项目使用贫血模式的原因一样,这个项目的业务相对简单,我们认为除了事件和渠道之外,长时间内不会有其他的属性加入。后面如果真的需要添加,最好做成关联表的形式,而不是再加属性了。
    2. 如果把创建积分明细看做是一个原子操作,那么返回boolean是更合理的,因为这样就已经知道操作结果了。只是在业务上,常常需要同步地拿到刚刚创建的明细ID,如果接口不返回,再查询会非常麻烦,在这里返回是总成本最低的方式,当然,代价就是部分调用处并不需要这个返回值。

    # 感想
    日常的工作中,我们常常也会考虑到各种做法是否违背某原则的情况,而且,这些场景总是两难的,刚开始的时候会死守某一条原则,硬着头皮把代码改成“明显有问题”的样子,后面会慢慢地做折中和妥协。
    2019-12-27
    1
  • William
    不能为了设计而设计.

    所以我认为以上两个问题都是与正常的业务设计,并不违反规则.


    第一个:
         需要关联事件与积分的关系.

    第二个: 为了后续的也许需要返回id字段无可厚非.
    2019-12-27
    1
  • 胖子
    我有一个疑问:接口设计、数据库设计和业务模型设计如何对应或过渡到MVC分层?
    2019-12-27
  • 正在减肥的胖籽。
    课堂讨论:
      1.第一个问题合理。1.积分流水表也需要展示积分从那个渠道赚取2.RPC接口失败超时补偿的时候也需要对应的字段来对应。3.业务对账也需要对应的业务字段,但是event_id和channel_id需要组成唯一索引。
       2.个人意见是不需要返回积分的ID,对上层业务来说只关注积分是否增加/消费成功。返回boolean或者void就可以。如果需要查询积分情况,已经有event_id和channel_id就可以反向查询。
    2019-12-27
  • Fancier
    都是合理的
    2019-12-27
  • 守拙
    课堂讨论Answer:

    1. 是合理的.如果credit_transaction表不包含event_id channel_id, 查询时下层系统(积分模块)和上层系统(营销模块)在业务上的交互就不可避免.



    2. 接口返回明细id或boolean都不违背单一职责原则. 业务如果需要明细id,返回明细id是更好的做法.否则返回明细id,boolean都可以.
    2019-12-27
  • Rain
    两个问题的答案都是依实际使用场景而设计。

    1. Trans id 和 channel id 在这个场景中不属于下层引用上层信息,积分是跟这两项息息相关的。重点在于你的业务,查询时是否需要这两项信息,如果需要那就没必要设计成两个表,相反,如果查询积分明细的时候需求就是只需要显示在什么时间点积分变动了多少,这样的话也是不需要存两个表,都不显示你存他干啥?

    2. 这个绝对是跟实际使用场景相关的,如果每次积分变动都会有一个按钮,点击可以查看本次积分变动的详细情况,那么这个id 必须要返回,否则如果只是给个提示,可以是void.
    2019-12-27
  • 小晏子
    课后思考:
    1. 积分表包含event_id和channel_id是合理的,对于积分业务来讲,产生积分的事件和产生积分的渠道都是业务的一部分,都是需要根据积分表能查询到的。所以这种设计是合理的,是必须要这么做的。
    2. 返回积分ID并不违反SRP,返回ID可以方便后面的查询。而且返回积分ID并没有给赚取积分消费积分增加额外的功能,没有破坏SRP。
    2019-12-27
  • 失火的夏天
    1.设计原则不是银弹,包含上层信息是因为业务上需要这些字段来获取信息,如果包装成一个类,依赖的内容就更多了,对调用方来说就不简介,不知道服务提供方到底需要什么。

    2.单一原则也是取决于具体业务的,如果消费和赚取的积分在后续还有操作,就需要再度去查询一下这个积分。还要多操作一次数据库,如果服务端直接有提供,就可以避开这一次操作。任何服务都是为了业务实现的。大部分场景都是面向sql编程。当然,如果业务场景不需要后续操作,就不需要返回了,不过统一来说,多一个返回值,也没什么影响。
    2019-12-27
  • 墨雨
    感谢王峥老师解答了我对 vo bo entity 的疑惑,系统做大之后这种分层的好处就显而易见了。对于接口耦合来说,接口本身是服务于业务的,设计原则指导代码设计,有时候刻板的完全遵守设计原则反而会增加系统的复杂性。
    2019-12-27
  • 醉比
    从工作开始一直遵从着三层分层的标准,也一直没有去深究原因,今天收获颇丰。
    2019-12-27
  • 再见孙悟空
    第一个问题我觉得是合理的,如果不这么做,那么上层业务中每个赚取或者消费积分的地方都要关联积分的字段,会将积分的赚取和使用分散在各处,不方便维护,也违反了高内聚地耦合。

    第二个问题,赚取或消费时返回 id 有一个好处是,可以立即使用,比如说赚取到积分后就可以不用刷新请求积分列表就能使用该积分。不知道理解对不对。
    2019-12-27
收起评论
21
返回
顶部