前言
爲什麼要首先談靈活性呢？其實是因爲博主從事軟件行業長久以來，最煩躁的，也是經常聽到身邊同事抱怨的一句話就是：我靠！天啦擼！需求又變啦！！！
其實需求變更就涉及到系統架構的特性（關注點）之靈活性。系統靈活性高，那麼任你需求如何變更，我自巋然不動！就像九陽真經中所說的“他強由他強，清風拂山岡。他橫任他橫，明月照大江。”反之，微末變更也會讓我哭爹喊娘，埋頭做碼畜！
既然要談靈活性，那麼我首先來嘗試定義下這個特性（非官方定義，秉承博客主旨：將所學所想用自己的語言表述出來）。
定義
系統提供的資源（能力或服務）能夠在有限的變化內支持儘可能多的潛在業務場景的能力。
有限
有限說明不是不能變化，而是變化很小，或者說變化的代價很小。控制變化本身也是有代價的，如果真要控制到無須任何變化可以支持近似於所有的業務場景，那需要付出的代價是很大的。道理很簡單，任何一件事要做到極致都是極其困難的一樣。
變化
變化就是衡量的主體，主要包括代碼變化和配置變化；而代碼變化又可以簡單分爲新增代碼和修改代碼。如果你瞭解軟件設計思想之配置優先原則和約定優先原則，以及軟件設計原則之開-閉原則，那麼就知道以上不同的變化實際會產生不同的變化代價。配置變化的代價小於代碼變化，新增代碼的代價小於修改代碼！
儘可能多
說明並不是要滿足所有的潛在業務場景，而是在一定的限度內，這樣才能更有效的控制成本。就好像我們做軟件設計時，首先需要確定清晰的問題域，確定問題域的目的就是明確系統邊界，即：
- 支持哪些特性？
- 永遠不支持哪些特性？
- 暫時不支持哪些特性？
- 後續可能支持哪些特性？
潛在
潛在意味着不是指已經支持的業務場景，而是那些將來可能會支持的業務場景，或者無法預料的業務場景。
實例一：某客戶關係管理系統（CRM）需要提供API給第三方系統
這個場景涉及到API的設計。API就是提供給第三方使用系統某種資源（服務或能力）的。那麼如果我們不考慮對其他架構決策特性的影響，單純提升API的靈活性，我們只需要牢牢把握住一點： 基於業務分析，提供儘可能完善的細粒度的原子服務API。這其實也是軟件設計原則之 - 單一職責原則的核心思想！這樣即使有新的業務場景需要支持，絕大部分情況下消費方都可以通過組合API的方式解決問題，當然這一定程度上增加了消費方使用API的難度，也就是降低了API的易用性。
考慮下一個CRM系統，其主要就是管理客戶資料的，那麼其實體信息一般包括客戶信息、用戶信息、賬戶信息、地址信息、客戶密碼信息…等等。按照以上儘量提供原子服務的思路，我們應該提供根據ID（或者關鍵字段）查詢每一種實體信息的接口，而不是隻提供一些組合接口，比如根據客戶ID查詢客戶信息和地址信息的接口。這樣將來需要提供一個只提供客戶信息場景時，我們就需要重新開發提供一個接口。
當然，讀者可能也會說，那我提供組合接口還方便了消費方呢，如果只提供原子接口，消費方要同時獲取客戶信息和地址信息時，需要調用兩次API呢！沒錯，所以之前博主強調了“單純提升API的靈活性”這個前提，而且消費方的便利與否，其實是後續博文會介紹的易用性範圍了。
實例二：某消息中間件需要支持多種通信協議
這個場景很常見，任何一個系統的接入層都希望能夠支持多種通信協議，以滿足不同的第三方系統接入需求。那麼碰到這種場景，我是不是要把所有常見的通信協議：HTTP、TCP、SOAP、FTP…等等全部實現呢？那麼大家思考一下就知道不會這麼選擇了！爲什麼呢？且不說協議種類本身很多，單說實現支持每一種常見協議，其代價都不是1+1這麼簡單的咯！
因爲協議層是處於軟件底層，所以其變動代價都是極其大的！我們要記住：越是底層的設計，變化的代價越大！因此，保證通信協議的靈活性對系統設計而且，尤其的有價值！
那麼在這種場景下，我們如何提升靈活性呢？其實我們學習面向對象編程的第一天就知道這個概念：抽象！我們抽象出一層協議適配層API，屏蔽上層對底層協議的訪問細節，也就是上層依賴於底層的抽象，而不是底層的具體實現！也是設計模式之適配器模式的核心思想。而且上層依賴底層抽象，實際上是延遲了對於具體實現的決策，對於動態編程也是由很大意義的！
當我們抽象出一層之後，那麼上層訪問底層只需要使用同一套抽象層API即可，至於底層具體使用什麼協議其實是不關心的。這樣，當我們想增加一個新協議時，代價就很小，而且基本對上層透明無影響。最終這樣的設計會極大的提升系統的靈活性！