目錄
文章目錄
- 目錄
- 架構師到底是做什么的？
- 什么是軟體架構？
- 軟體架構的本質
- 架構的程序，即：建模的程序
- 業務建模
- 系統建模
- 抽象能力
- 抽象縱向層次
- 抽象橫向模塊
- 抽象的評估原則
- 抽象的方法論
- 參考檔案
架構師到底是做什么的？
什么是軟體架構？
在百度百科上的定義：
架構，又名軟體架構，是有關軟體整體結構與組件的抽象描述，?于指導?型軟體系統各個方面的設計，
在 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》：
參考檔案
《如何畫好一張架構圖？》
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/98768.html
標籤：其他
上一篇：鴻蒙工程結構簡析