你是否正在被不斷變化的需求折磨得焦頭爛額？！

　　你是否在為繁冗復雜項目抓耳撓腮？！

　　相信這是很多人現在正面臨的問題。我們在學習軟件架構時經常能看到擁抱變化的字眼，我們也知道什么是擁抱變化，也知道擁抱變化是解決上述問題的最優途徑。然而，如何擁抱變化才是解決問題的關鍵所在。每每此時，各種書本都會把路標指向設計模式，各種架構模式等，大家每個人看了以后大都恍然大悟，而付諸于實踐時則仍舊一臉茫然。那么如何做到擁抱變化呢？

首先，要從軟件架構的根本說起。我們為什么要進行軟件架構設計？！答案很簡單，因為有變化，并且是很多的不斷的往往難以容忍的變化。如果沒有變化，世界上就不會沒有軟件架構，今天很多做軟件的人肯定在做從事職業。相信這么說沒幾個人會持反對意見。

其次，任何軟件項目都要解決實際的業務，不解決業務的軟件根本不存在，而變化則來自于要解決的業務問題。也會你認為這是廢話，但明白這點很重要。大家都知道，解決問題并不難，發現問題才是最難得。業務是解決現實世界中的某一類問題，因此它有特定的規律，源子于業務的變化則同樣擁有這些規律。明白這點，我們就向成功邁出了關鍵的一步。

第三，既然變化有規律，那么就可以分析總結。因為變化來自業務，所以要從業務入手，通常業務可以劃分為業務流程和業務單元，如圖1：

圖1

圖1是一個抽象的業務1，從A到E是一個完整的業務流程，其中A，B，C，D，E是業務中的業務單元。那么我們可以總結出業務的變化規律，如圖2：

圖2

顯然，業務變化僅有4種情況。拋除流程和單元均不變得情況（灰色），實際上只有三種，其中最容易遇到的就是一個變化一個不變（綠色）。二者均變化的情況很少，當出現變化時，要么是項目定位出錯，注定失敗；要么業務劃分粒度不夠或不合理。因此，通常我們重點把握的變化只有兩種，分別是：第1，業務流程不變，業務單元發生變化；第2，業務流程變化，業務單元不變。下面我們就對如何把握這兩種情況做一一說明。

 　　業務流程不變，業務單元發生變化

　　這種變化最容易理解，舉個最簡單的例子。當我們去商店/超市購物時，通常的流程都是首先選購商品，然后付賬，最后交易完成。像這樣的業務流程應該說自商店/超市出現起到現在都沒有發生變化過，但是支付方式卻發生了很多變化，從最早的金屬貨幣，到后來的紙幣，再到信用卡，甚至今天的手機支付等等。如此相信不難理解下圖：　

圖3

那么此類變化該如何解決呢？通常我們可以為此類業務構建一個比較穩定的框架(Framework)，在可能變化的地方(如圖3中的支付)抽象出接口，使用依賴倒置等方法實現可能變化，然后根據條件，調用實際的實現（如選擇紙幣支付方式）；

 　　業務流程變化，業務單元不變

　　以訂票為例說明此類變化，如下圖：

圖4

由圖4可以看出，對用戶來說同樣都是訂票業務，事實上有不同的實現方式(業務流程)，但是其中的某些業務單元，如訂票，支付，配送完全一樣。由此可以總結出此類變化的特點，就是在不同的情況下，同樣的業務可能要通過不同的組合(業務單元)實現。相信這點不難理解。那么此類變化該如何解決呢？現在很流行的SOA為我們提供了很好的解決方法。我們可以將每個業務單元以服務的形式發布，從而解決了業務單元直接的耦合，在需要的時候裝載不同的單元服務，從而實現不同的業務流程，甚至靈活構建新的業務而不必擔心對現有業務造成任何影響。

最后，通過以上對業務變化的分析，相信大家對軟件架構設計中如何擁抱變化有了一些新的認識。事實上，今天很多的軟件架構方法都是解決業務變化中的某一類型的變化，如SOA，AOP等等，只是它們的關注點不同。只要把握了它們的關注點，相信擁抱變化不是難事！