16.6　不能脱离实现技术

提炼模型时，如果只专注于业务模型，而忽略了实现技术，这样有可能导致因无法实现而最终搁浅。

三年前，我曾经开发了一款应用软件，当时为模型设计了回滚处理，由于使用了组合模式，当时并没有考虑到嵌套事务的回滚问题，当时的问题是：在一个树形对象图中，如果子对象的事务回滚了，我们需要对其父对象的所有子对象的事务回滚，并且父对象的事务也要回滚。比如，对象a有三个子对象b、c和d，当b和c提交了操作，而d对象的事务需要回滚时，那么已经提交事务的父对象a和兄弟对象b和c都需要回滚。由于当时只能使用简单的JDBC事务，这种需求是不能被支持的，虽然JTA（Java Transaction API）^[1]2事务可以实现（执行子对象提交之前，在父对象a设置回滚点，如果b, c提交成功、d失败，可以回滚到父对象a设置的回滚点），但是由于其中种种原因，我们并不能使用JTA。

当时的开发工作已经完成了3/4，幸运的是，当时碰巧读到一篇文章，提到了Ebay电子商务网站的应用并没有使用数据库事务管理，由此大受启发。我开始思考不是使用传统的数据库回滚，而是实现了业务操作的回滚，即如果d操作需要回滚，我让a、b和c对象执行业务上的回滚操作。试想，如果不是受这篇文章的启发，可能此项目将会失败。

我这里要强调的是，在任何时间，都要联系到实现技术。有时候即使技术能够实现，对你的团队来说，可能由于大家都未曾考虑过这些问题，当最终摆在面前时，大家便会手足无措。实现技术是多种多样的，即便你用到的实现技术不是最好的，但它至少能解决你的问题；倘若刚开始你没有这样做，即便有最简单的技术实现，也可能因为你当时的无知而失败。

联系到技术有利于把握时间，成本等其他因素，降低其中的风险。上述例子之所以可以考虑实现业务上的回滚，是因为我们的应用从一开始就支持那些业务的回滚操作，如果不支持，那么重新开发将是极其复杂的事情，因为会引起核心的大修改，很可能导致该软件半途而废。

[1]是Java EE分布式事务处理的APIs，是关于跨越多个XA资源的分布式事务的Java EE标准。