變更孤島
1 定義
變更孤島，是一種創建可演化的架構的模式。其主旨是將大型系統分割成多個獨立可替換的部分，這些可替換的部分在之後的架構演化中逐步替代以適合的架構形態，針對可替代性而不是可重用性設計。
2 上下文和問題
在構建系統的時候，不一定從一開始就能設計出合適的架構。此時需要先構建一個初始的架構，並使其能隨對系統理解的加深而逐步進行演化。
3 解決方案
對於上述可演化的架構，存在一種構建方法，使用此方法構建的架構具有適應性，能夠在特定的時間點轉換爲合設的架構。這種構建方法需要遵循以下的原則：
將大型的系統分割成“變更孤島”
針對可替代性進行設計，而不是可重用性
最小化共享依賴，重點關注自治和冗餘，而不是重用
先將系統按變更作用的範圍進行大粒度的劃分，劃分出的各個部分的變更僅影響系統內部，而不會影響彼此。此時劃分的部分稱爲“變更孤島”。之後的架構演進，圍繞替換這些變更孤島，而不是重用或者重構這些變更孤島來進行。即設計出提供某個孤島相同能力的子系統時，對此孤島進行替換。
而對於子系統，也可採用這種方式進一步進行變更孤島的劃分、替換，直到系統的架構全部清晰。
由於劃分的孤島彼此耦合很小，功能內聚，可到達最小化共享依賴的目的。因此對孤島進行冗餘、替代都非常容易。這樣可方便的對某個孤島的架構和實現進行實驗，一旦失敗也可以方便的回退到原架構。
比如，在服務的劃分中，經常會劃分成前端服務、業務邏輯服務和數據服務，它們之間的調用關係如下：
前端服務、業務邏輯服務、數據服務都是功能內聚的部分，可作爲變更孤島，即他們內部的變更在內部消化，不影響到使用方。但如果直接按調用關係組織這些服務，是無法達到變更孤島的架構目標的，因爲前端服務使用了業務邏輯服務，會受業務邏輯服務變更的影響；而業務邏輯服務使用了數據服務，又會受數據服務變更的影響。這種架構是無法實現不同“孤島”間的松耦合的。
從長期來看，業務邏輯的變化比數據存儲技術和前端技術的變化慢得多，依賴應向着更穩定的方向，因此前端服務和數據服務依賴業務邏輯服務是合理的。而數據服務、前端服務應該是能隨需求的變化或技術的迭代，快速變更的。這樣，我們通過依賴反轉方法，將業務邏輯服務對數據服務的依賴關係反向。如下圖：
按這種方式進行調整之後，業務邏輯服務只依賴抽象的數據接口，而不再依賴具體的數據服務了。而數據服務只要實現數據接口，無論內部怎樣變更，替換成哪種實現技術，都可以支撐業務邏輯服務，並且這種變化不會被業務邏輯服務感知。
而業務邏輯服務只要對前端服務提供的接口不變，也可以有效的對前端服務屏蔽變化。這樣，前端服務、業務邏輯服務、數據服務就能達成變更孤島的架構目標了。
下面擴展一下業務邏輯服務和數據服務之間的關係。在實際的系統設計中，經常出現多個業務邏輯服務都使用數據服務的情形，直接的調用關係如下圖：
這種架構中，數據服務被業務服務A和B重用（共享），但卻使業務服務A、業務服務B和數據服務產生了強耦合：不但讓業務服務A、業務服務B都感知了數據服務的變化，而且從業務服務A出發產生的數據服務變更也會被業務服務B感知，業務服務B不得不因爲業務服務A的變更而變更。
從架構層面來看，對服務的重用越多，服務間的耦合就會越重。重用並非服務間良好的組織方式。如果從變更孤島的思路來思考，業務服務A和業務服務B看數據服務，都應該是可替換的。可以採用依賴反轉將重用使用關係改變。如下圖：
在這種關係下，業務服務A和業務服務B都不再依賴數據服務，而是依賴彼此定義的抽象數據接口。數據服務的變更可封閉在數據服務內部。而且，可以爲業務服務A和業務服務B使用不同的數據服務實現，增強了系統的擴展性。這就是針對替代性而不是可重用性進行設計的意義所在。如下圖：
4 優點
架構中的部件功能內聚，彼此松耦合，可逐步演進；
系統各個部分可方便的替換、回退，利於實驗性特性的實現，比如A/B測試；
複雜系統架構演進時，可劃分成多個變更孤島各自進行架構演進。由於孤島之間互不干擾，因此係統演進可從容地分階段、分層次地開展。
由於孤島可替代，而不是被依賴，這種架構符合依賴倒置原則（DIP），有利於將具體技術決策延後，增強架構對變化的適應性。
5 問題和注意事項
一開始的劃分不宜粒度太細。孤島的劃分時，優先從現有功能可替代角度思考。避免一開始就被架構是否優美、部件如何共享如何重用等無關功能解耦的問題束縛住手腳。
6 應用場景
對大型系統進行微服務劃分，但初期無法完全理解系統，不能細粒度的劃分微服務時；
將現有大型系統遷移至微服務架構，存在某些因素無法判斷微服務拆分是否合理時，可採用這種可演化的架構方式；