一般软件都有一些重要的实体对象,这些对象属于该软件的核心数据,对于这些对象需要制定合适的删除策略。首先我们讲一下最简单的删除策略,那就是不删除,一旦产生就长期存在。比如说,你现在为一个蛋糕店开发一个会员卡系统,每张卡除了卡号,还有用户姓名、手机号、购买记录。该用户卡支持以下三种业务

  1. 只要是出示会员卡就打八折
  2. 每次消费满十次就返十元现金
  3. 每次消费满一百元就返十元现金

这种卡只要有人进店消费就免费送,也不存在销卡的说法,客户不乐意来了自己把卡丢进垃圾桶就可以。当然也可能存在死心眼的客户非要主动到店里面销卡,那么店员把卡接过来丢进营业台下面的垃圾桶就行了。这个软件系统中是否需要实现卡片删除流程?我觉得没有必要。这个例子告诉我们最好的策略就是什么都不做。

如果一定要支持重要实体对象的删除,那么到底该怎么做呢?再举一个生活当中的例子,某银行管理系统,用户的银行卡是非常重要的实体对象,但是又要必须支持用户来银行销卡。销卡的时候需要关注很多事项,比如说,这个卡是否是工资卡,是否关联了股票交易,基金交易,第三方理财交易,是否有房贷,车贷,信用贷、是否关联公积金,社保等等。这么多关联业务,都需要解除掉,才能销卡,否则就会出现巨大的业务漏洞,问题是这些业务自身也比较复杂,解除业务本身也不简单。那么作为销卡流程到底该怎么实现?

下面有两种策略,第一种是傻瓜策略,只要存在关联业务就不让销卡,至于说解除关联业务这件事本身,由其他流程自己去保证,销卡流程自身不关心,该流程就认死理,只要存在关联业务就不让销卡,不存在关联业务随便销卡。第二种是精明策略,由销卡流程发起,自行驱动各种接触关联业务的流程,一把清,保证每次发起销卡业务都可以轻轻松松搞定。那么现实生活中,银行采用的事那种策略呢?毫无疑问是第一种。

你到银行销卡,不是件轻松的事情,如果这张卡是一张无用卡,不但一分钱没有而且从来没有开通任何业务,那么恭喜你,很快就可以办妥。如果你这张卡用了很多年,各种金融业务用的都是这样卡,现在你要移民了,要和该银行说拜拜了,那么你要做心里准备,可能要花半个上午的时间,并且不一定只在银行就能办妥,可能要跑好几个地方。

在业务比较复杂,开发人员能力有限的情况下,最好用傻瓜策略,万万不要挑战自己的设计能力。精明策略是码农容易自己走进去的陷阱,一旦踏进去会带来无穷无尽的故障。

相关文章