軟件系統發展演變過程

一、引言

「以銅爲鏡，能夠正衣冠；以古爲鏡，能夠知興替；以人爲鏡，能夠明得失。」，知道歷史，明白爲何會出現這些問題，歷史上又是如何解決這些問題，如今還存在哪些問題。在學習某個知識點的時候也是如此。

在學習的路上老是會讓人盲目，你們都說好，那就是好，套以現成，拿以賣弄，問不知因此然，貽笑大方。學習須要深刻，學習一個技術，要知道技術的歷史交替、興衰勝敗，而後分析，理解，總結，完善。

---

二、發展歷程

上圖由上而下的順序就是軟件架構的發展歷程。

1. 結構化

幾乎每一個程序員最初學習變成語言的時候寫的都是結構化代碼

public class Demo {

	public static void main(String[] args) {
		int a = 1;
		String b = "hello";
		System.out.println(b);
		
		for (int i = 0; i < 3; i++) {
			if (i == a) {
				System.out.println(b);
			}
		}
	}

}

惟一入口main方法，自上而下順序執行，定義變量，循環，判斷，獲得結果，結束。

結構化架構就是如此，分爲多個模塊互相獨立，其中一個是入口模塊(main),其中操做就是其餘子模塊(方法),入口模塊調用子模塊的方式運行。

可是在日益複雜的需求下，這種架構很難知足，可是並不是被淘汰，由於結構簡單，而且獨立，因此能很好的與硬件所結合，單片機程序很是適合這種思想去寫代碼。

2. 面向對象

結構化設計又被稱爲面向過程，只注重運行過程的程序，面向對象則顛覆了這種想法，對象能夠理解爲「人」，舉個例子，面向過程就是A拿起蘋果，面向對象就是不去考慮誰拿起了什麼，而是考慮這裏面有幾個對象(人、蘋果兩個對象),而後再去實現人拿起蘋果這個動做。

面向對象並非單純的封裝、繼承、多態，而是在分析需求的時候，優先想到對象，在聯繫對象去構想動做。提取出重複的動做爲方法，不論是誰拿起了什麼，只須要調用拿起這個方法便可。

相比起結構化設計，面向對象無疑是在業務分析和簡潔代碼上都有很大的優點，可是缺點也很明顯就是性能差(這是相對結構化程序性能差),佔用大量的內存空間,不少時候使用一個方法可是卻要去建立一整個類。

3. 設計模式

設計模式其實本質上仍是面向對象，只是將面向對象用的更加靈活多變，更加針對性，同時也儘量彌補一些面向對象所存在的缺點，能夠說是對面向對象的一種使用方法，理論上能夠設計一個徹底彌補面向對象缺點的設計模式，可是理想很豐滿，現實很骨感，正確的方式就是針對特定的場合使用合適的設計模式。

3. DDD

我認爲DDD是將面向對象的思想擴大化，若是把類理解爲領域，那麼劃分領域就是劃分類，領域種的子領域就是方法，限界上下文就是類與類、方法與方法之間的關係和界限。

可是DDD提出的一點確實與傳統架構有着很大區別，那就是在分析需求，劃分領域時，傳統方案是由架構師、技術經理一塊兒分析後，再分派安排到各組各人任務，而DDD提倡的是全員參與討論劃分領域，統一建模語言。

很難說兩種方式的好壞，與傳統方式相比較DDD提倡的討論法會花去更多的分析需求的時間，並且實現起來比較困難，可是對全員理解業務和總體流程更加有利。

4. DCI和DSL

DCI是數據Data 場景Context 交互Interactions的簡稱，DCI是一種特別關注行爲的模式。聽上去彷佛很厲害，但其實就是對DDD一種靈活變化，本質上仍是DDD的領域思想。

DSL 領域特定語言（英語：domain-specific language、DSL）指的是專一於某個應用程序領域的計算機語言。DSL本質上其實就是對DCI的一次改造升級，因此追其根本仍是DDD。

就我我的理解不管是DCI仍是SDL都只能算是靈活改動的DDD思想，就像上面所說的設計模式與面向對象同樣，設計模式再多樣化，本質上仍是面向對象。

5. 微服務

微服務是當下熱門話題，微服務就是將一個大的系統拆分紅若干子系統，單獨部署，單獨維護。這樣的好處是顯而易見的，那就是系統高度解耦，互不影響，可拓展性也大大加強，須要增長新的功能，就再開發一個子系統，輕鬆拓展。並且每一個系統都與語言無關，A子系統能夠用java語言編寫，B子系統能夠用C#編寫，語言多樣化。就算那個系統崩潰了，對總體影響微乎其微，只要修復子系統便可。

因此微服務架構的好處就是獨立，兄弟姐妹衆多，互相獨立，獨立學習(升級)，生兒育女(拓展)，而且都已經獨立了不是小孩子，不須要在一個你們庭中集中生活(不須要集中管理)。

可是這樣形成的後果就是，若是不少兄弟姐妹遭遇困難須要幫助(負載均衡問題)，那就須要你們各自獨立承擔，成本很是高。若是弟弟A找姐姐B借的100元錢是姐姐B向哥哥C借的，一旦弟弟A還不起這100元的死後，姐姐B也很難還哥哥C的錢(事務回滾問題)。當父母須要把兄弟姐妹聚起來排個輩分從大到小，會由於孩子很是多並且很是分散一個個通知到而費勁經歷(集中測試和運維問題)等等系列的問題須要處理。

因此微服務的成本很是高，若是在中小型項目上實施，不論實施難度，光金錢成本和時間成本還有之後的維護成本都很是高。

---

三、小結

總結了一大堆，其實能夠發現，整個軟件系統架構的演變過程其實並無拋棄原先的東西。

不管如何，咱們在寫業務接口的時候依然是結構化的順序在寫。

而且不管是設計模式仍是DDD依然在用繼承、封裝、多態。

設計模式更是對一些特定問題提出解決方案。

從每個階段的優缺點能夠看出，在結構化時期，由於重複模塊太多，隨着系統越來月龐大，維護起來會愈來愈困難，因而面向對象應運而生。

面向對象架構實現後，面臨的又是過多的浪費系統資源而致使系統性能差勁，並且系統愈來愈龐大之後，繼承使用過多也會致使系統可讀性變差。

設計模式的出現就解決了面向對象系統上不少的弊端，例如過多建立對象等等一系列問題。

不管是哪種架構方案都是在以往的經驗上不斷累積的過程。就像武林大俠練武功同樣，首先找一本武功練習，熟練之後研究它的本質原理，這都是遵循原理在使用，而後再根據本身的經驗總結出合適本身的，適合當前使用的「武功」。

軟件設計也是如此，使用它，理解它，總結它，而後在合適的地方使用本身總結出來的設計。這是一個不斷完善的過程，架構其實就是開發經驗的一種體現。