軟體架構師之擁抱變化

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

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

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

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

 

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

 

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

圖1

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

圖2

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

 

　　商務程序不變，業務單元發生變化

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

圖3

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

 

　　商務程序變化，業務單元不變

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

圖4

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

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