軟體架構的本質
目錄
架構師到底是做什麼的？
什麼是軟體架構？
在百度百科上的定義：
架構，又名軟體架構，是有關軟體整體結構與元件的抽象描述，⽤於指導⼤型軟體系統各個方面的設計。
在 Wikipedia 上的定義：
Architecture is both the process and the product of planning, designing, and constructing buildings or any other structures.
ISO/IEC 42010:20072 中對架構的定義：
The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
軟體架構的本質
架構體現的是整體結構和元件之間的關係：
- 本質是為了管理複雜性。
- 本質就是對系統進行有序化重構，不斷減少系統的 「熵」，使系統不斷進化，以符合當前業務的發展，並可以快速擴充套件。
上述表達了架構的核心目的：
- 管理複雜性
- 效率最大化
以及架構的兩個主要變化來源：
- 一個是以改善軟體品質為目的的內在結構性變化；
- 另外一個是以滿足客戶需求為目的的外在功能性變化。
無論是何種變化，架構都是在不斷的判斷和取捨，在業務需求和系統實現之間做權衡，從而來應對未來變化的不確定性。
架構的過程，即：建模的過程
架構的過程其實就是建模的過程，即：模組的拆分和整合。
Linus 03 年在聊到拆分和整合時有一個很好的描述：
讓我們認識到一種現象，把複雜系統拆分成模組，似乎並沒有降低整個系統的複雜度。它降低的只是子系統的複雜度。而整個系統的複雜度，反而會由於拆分後的模組之間，不得不進行互動，變得更加複雜。
可見，系統拆分就是實現一個架構的過程，基本出發點是為了效率，通過架構的合理拆分（無論是空間還是時間上的拆分），最終目的讓效率最大化。
現實世界到軟體世界的過程，是一個不斷抽象的過程，即：不斷的建立模型。
從現實世界到業務模型，從業務模型到概念模型，從概念模型到設計模型，通過不斷的抽象去粗取精，形成對現實世界的層層抽象，所以架構的過程其實就是建模的過程。
百度百科定義：
建模就是建立模型，就是為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。
《Thinking in UML》定義：
建模（Modeling），是指通過對客觀事物建立一種抽象的方法用以表徵事物並獲得對事物本身的理解，同時把這種理解概念化，將這些邏輯概念組織起來，構成一種對所觀察的物件的內部結構和工作原理的便於理解的表達。
從上述兩個定義上基本可以瞭解到建模就是抽象，對業務或現實世界的抽象，架構的過程是建模的過程。
業務建模
理解業務本身，需要對行業背景有深入的瞭解，最終才能夠產出《業務核心流程圖》和《業務功能模組圖》。
系統建模
通過業務建模完成了從現實世界到業務模型的構建，在此基礎上，如何通過抽象完成業務模型到設計模型的對映，這是系統建模要解決的問題。
系統建模一定是在業務建模的基礎上，完成業務需求到系統模型之間的對映；這其中涉及業務功能到系統能力、業務流程到資料流程的對映；系統建模更強調職責、依賴、約束關係，用於指導研發的落地實現。
抽象能力
Haskell 語言的設計者之一 Paul Hudak 曾說過一句略帶誇張的話：程式設計中最重要的三件事是：抽象，抽象，抽象。那麼，什麼是抽象？
百度百科定義：
從具體事物抽出、概括出它們共同的方面、本質屬性與關係等，而將個別的、非本質的方面、屬性與關係捨棄，這種思維過程，稱為抽象。
抽象就是做減法和做除法。通過捨棄非本質和無關緊要的部分，著眼於問題的本質，去粗取精；通過透過現象看本質，發現不同事物之間的共同之處，異中求同，同類歸併，也就是做除法。建模過程是共性抽象，通過不斷的抽象達到某個狀態為止。
Wikipedia 關於抽象的定義中有一個關於報紙的例子：
- 我的 5 月 18 日的《舊金山紀事報》
- 5 月 18 日的《舊金山紀事報》
- 《舊金山紀事報》
- 一份報紙
- 一個出版品
這五句話中，我們可以感受到抽象的層次，抽象層次越高，細節越少，普適性越強。
抽象縱向層次
再比如下圖中關於網路模型的抽象，關於作業系統核心的抽象，我們可以明顯的看到不同層次的抽象，就是過濾不同的資訊，最終留下來的資訊才是當前抽象層次所需要的資訊。
從系統設計實現上來說，抽象層次越高，越接近設計，越遠離實現，同時抽象的模型越不受細節的羈絆，穩定性越高，普適性越強，可重用性就越高。
那麼，抽象的劃分層次的依據是什麼？原則又是什麼？
依據：
- 以抽象角度分層（可能一層是多角度的聚合）。
- 面對變化分層（用層次隔離變化）。
原則：
- 公用的往下走。
- 個性的往上走。
- 下層可以獨立於上層存在。
- 控制下層的變化。
抽象橫向模組
我們還需要考慮的抽象的邊界。如果說層次考慮的是縱向維度的表達（分層次），那麼邊界考慮的是橫向維度的表達（分功能模組）。如何確定邊界，一個總的原則是按照職責進行劃分，這裡的職責其實也就是分工。
一旦職責確定，在做建模分析時就不需要把整個業務大局放進來從頭到尾去分析一遍，只需要考慮當前分工下的上游和下游即可，這樣的資訊量大大減少，自然的，面對的領域複雜度也會降低到一定程度。
抽象分界的依據就是要確定：
- 核心實體。
- 核心實體業務流程。
- 核心實體生命週期。
抽象的評估原則
高內聚，低耦合是評估一個抽象的基本原則。
- 內聚是一個模組內部各成分之間相關聯程度的度量。
- 耦合是軟體結構中各模組之間相互連線的一種度量。
抽象的方法論
抽象有兩種方法，一種是自頂向下，另一種是自底向上。
- 業務建模，是從小到大，從區域性到整體，自底向上的歸納、演繹的抽象過程。
- 系統建模，是從大到小，從整體到區域性，自頂向下的拆解、切分的抽象過程。
下面這張圖來自於《Thinking in UML》：
參考檔案
《如何畫好一張架構圖？》