对一般订单生成过程的抽象过程的思考

一般的电子商务网站,都会有生成订单这个业务,最近自己也正好负责的是这块业务,所以自己也好好理了理这块的业务。
其实不管是订单部分的业务代码,还是其它部分的业务代码。一个不小心就会写成流程式的代码。写成流程式的代码,我个人觉得主要有一下几点:

1. 代码里面充满了很多注释,注释按照步骤写下来.1,2,3,4,5,6.
2. 代码没有层次性,具体的层次性可以参照 关于业务分层 。还有一个就要设计的就是 抽象一致性
3. 代码没有模块性,具体的体现就是一件事,会在很多地方穿插进行。举个例子,订单里面会涉及到 邮费 ,计算邮费的值会遍布在整个订单流程。这样的坏处就是,出了问题以后,一下子定位不到问题出现在哪里。

订单的流程,按照普通的过程来说。会有生成一下几步

1. 计算优惠(包括活动,红包等)
2. 计算邮费
3. 生成支付信息
4. 生成订单
5. ......

先来分析下订单的整个流程,发现它其实是一个黑盒。页面传了一批参数过来以后,我们封装了一下,然后丢进这个黑盒,出黑盒里面出来的是最后生成的订单实体。
我们首先对整个过程建立一个最高层的抽象。即:

 public interface Builder{
        public void do(Context context);
    }

这样子，每一部分都在做自己的事情,如果涉及到和其他模块进行通信的话,可以借助这个上下文 Context 。这样子就可以在很大程度上实现模块化。至于里面更小的抽象,我们还可以根据不同的层次抽象出更多的Builder来让我们的代码可以模块化。
至于怎么讲这些Builder串联起来。一开始,我觉得这个过程可以看做是一个订单实体的构建过程,所以一开始我用的是 建造者模式 ,但是发现把这些东西都放在一个类中,在维护上是在是太费力气，所以后来我就用了 责任链模式 的变形(类似 struts 里面的拦截器)。

经过这样子的抽象以后,你会发现。每个类都在做自己的事情,而且不用写大量的注释来注释整个流程。关于流程的扩展的话,因为整个架子在那里,所以如果是扩展流程的话,那么在已有的链上加一个节点就OK了,如果是业务内部的扩展的话,只需要在相应的类里面扩展,不会涉及到其他的类。

这里写到了关于 建造在模式 和 责任链模式 ,我准备下一个提问中说说关于设计模式的一些事。
希望大家可以指点。