以前做過一個產品，共分為三層：平臺層，應用服務器層，應用層。其中有一個業務流程，實現是在應用層，但它那里的信息不全，需要通過應用服務器層向平臺層獲取必要的業務數據，然后通過應用服務器層控制業務流程。當時考慮這個結構的時候，主要的出發點就是業務和控制分離，將業務處理從平臺層剝離開來。當時，在具體是實施過程中，我們工程師對這種結構抵觸心理很強烈。他認為我們的業務開發非常的繁瑣，而且經常要貼“狗皮膏藥”。

先拋開上面這個實例的設計思路，這里面反映出一個問題：軟件開發過程中，軟件體系結構同樣需要“重構”。

結合經典的《重構》，這里簡單的寫一下軟件體系結構重構的定義，原因，設計，方法。僅作拋磚引玉，希望能和大家一起思考。

何謂重構

對軟件體系結構的一種調整，目的是在不改變其“外在行為”的前提下，調整其結構，使其易于修改，維護和理解。

為何重構

1、使整個系統易于添加新的功能。為系統添加新功能將會非常的容易。

2、調整系統中各個模塊的功能，角色，使整個系統更容易理解。
何時重構

由于系統結構的重構成本非常高，所以要選擇一個合適的重構時機。

1、為系統添加功能時重構。此時項目進度壓力如果非常大，這放棄此時重構。

2、軟件第一個版本開發完畢后重構。在第一個版本開發完畢，第二個版本開發之前，根據第一個版本的開發經驗，對系統進行重構。

3、開發出系統原型時進行重構。開發出一個系統的原型的時候，如果發現系統需要重構，這及時的進行，這個時候重構成本較低，但對是否重構決策要求較高。

重構的必要條件

重構之前必須為軟件系統建立一個可靠的、自動化的功能測試環境，這樣才能有效防止重構帶來的危害。好的測試時重構的根本。重構之前，首先檢查自己是否有一套可靠的測試機制。這些測試必須有自我檢驗（selfchecking）能力。

重構與設計

系統架構層次的重構，因為重構的成本相對較高，所以預先設計的程度要相對較深，要盡量考慮系統可能遇到的情況，方案要適當的靈活和強固。盡量減少系統結構的重構。

軟件體系結構的重和代碼的重構的區別

1、針對的層次不同：一個是系統結構層次的，一個是代碼層次的。

2、重構成本不同，系統結構的重構成本相對較高。

3、是否重構的決策者不同。

4、重構的時機不同。