以前做过一个产品，共分为三层：平台层，应用服务器层，应用层。其中有一个业务流程，实现是在应用层，但它那里的信息不全，需要通过应用服务器层向平台层获取必要的业务数据，然后通过应用服务器层控制业务流程。当时考虑这个结构的时候，主要的出发点就是业务和控制分离，将业务处理从平台层剥离开来。当时，在具体是实施过程中，我们工程师对这种结构抵触心理很强烈。他认为我们的业务开发非常的繁琐，而且经常要贴“狗皮膏药”。

先抛开上面这个实例的设计思路，这里面反映出一个问题：软件开发过程中，软件体系结构同样需要“重构”。

结合经典的《重构》，这里简单的写一下软件体系结构重构的定义，原因，设计，方法。仅作抛砖引玉，希望能和大家一起思考。

何谓重构

对软件体系结构的一种调整，目的是在不改变其“外在行为”的前提下，调整其结构，使其易于修改，维护和理解。

为何重构

1、使整个系统易于添加新的功能。为系统添加新功能将会非常的容易。

2、调整系统中各个模块的功能，角色，使整个系统更容易理解。
何时重构

由于系统结构的重构成本非常高，所以要选择一个合适的重构时机。

1、为系统添加功能时重构。此时项目进度压力如果非常大，这放弃此时重构。

2、软件第一个版本开发完毕后重构。在第一个版本开发完毕，第二个版本开发之前，根据第一个版本的开发经验，对系统进行重构。

3、开发出系统原型时进行重构。开发出一个系统的原型的时候，如果发现系统需要重构，这及时的进行，这个时候重构成本较低，但对是否重构决策要求较高。

重构的必要条件

重构之前必须为软件系统建立一个可靠的、自动化的功能测试环境，这样才能有效防止重构带来的危害。好的测试时重构的根本。重构之前，首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验（selfchecking）能力。

重构与设计

系统架构层次的重构，因为重构的成本相对较高，所以预先设计的程度要相对较深，要尽量考虑系统可能遇到的情况，方案要适当的灵活和强固。尽量减少系统结构的重构。

软件体系结构的重和代码的重构的区别

1、针对的层次不同：一个是系统结构层次的，一个是代码层次的。

2、重构成本不同，系统结构的重构成本相对较高。

3、是否重构的决策者不同。

4、重构的时机不同。