一般软件都有一些重要的实体对象，这些对象属于该软件的核心数据，对于这些对象需要制定合适的删除策略。首先我们讲一下最简单的删除策略，那就是不删除，一旦产生就长期存在。比如说，你现在为一个蛋糕店开发一个会员卡系统，每张卡除了卡号，还有用户姓名、手机号、购买记录。该用户卡支持以下三种业务
- 只要是出示会员卡就打八折
- 每次消费满十次就返十元现金
- 每次消费满一百元就返十元现金
这种卡只要有人进店消费就免费送，也不存在销卡的说法，客户不乐意来了自己把卡丢进垃圾桶就可以。当然也可能存在死心眼的客户非要主动到店里面销卡，那么店员把卡接过来丢进营业台下面的垃圾桶就行了。这个软件系统中是否需要实现卡片删除流程？我觉得没有必要。这个例子告诉我们最好的策略就是什么都不做。
如果一定要支持重要实体对象的删除，那么到底该怎么做呢？再举一个生活当中的例子，某银行管理系统，用户的银行卡是非常重要的实体对象，但是又要必须支持用户来银行销卡。销卡的时候需要关注很多事项，比如说，这个卡是否是工资卡，是否关联了股票交易，基金交易，第三方理财交易，是否有房贷，车贷，信用贷、是否关联公积金，社保等等。这么多关联业务，都需要解除掉，才能销卡，否则就会出现巨大的业务漏洞，问题是这些业务自身也比较复杂，解除业务本身也不简单。那么作为销卡流程到底该怎么实现？
下面有两种策略，第一种是傻瓜策略，只要存在关联业务就不让销卡，至于说解除关联业务这件事本身，由其他流程自己去保证，销卡流程自身不关心，该流程就认死理，只要存在关联业务就不让销卡，不存在关联业务随便销卡。第二种是精明策略，由销卡流程发起，自行驱动各种接触关联业务的流程，一把清，保证每次发起销卡业务都可以轻轻松松搞定。那么现实生活中，银行采用的事那种策略呢？毫无疑问是第一种。
你到银行销卡，不是件轻松的事情，如果这张卡是一张无用卡，不但一分钱没有而且从来没有开通任何业务，那么恭喜你，很快就可以办妥。如果你这张卡用了很多年，各种金融业务用的都是这样卡，现在你要移民了，要和该银行说拜拜了，那么你要做心里准备，可能要花半个上午的时间，并且不一定只在银行就能办妥，可能要跑好几个地方。
在业务比较复杂，开发人员能力有限的情况下，最好用傻瓜策略，万万不要挑战自己的设计能力。精明策略是码农容易自己走进去的陷阱，一旦踏进去会带来无穷无尽的故障。
