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