1.認識架構

1.1生命周期：

• 萬物皆有生命周期

• 生命周期包含各種活動，活動的推進是生命周期的必要因素（對象的行為）

• 生命周期裏面的活動拆分後，形成若幹新的生命周期

• 拆分後主體不變的是核心生命周期，變化了的是非核心生命周期

• 每個主體的生命周期變化都累積在自身，這個就是所謂的內聚（面向對象分析新思路）

• 生命周期拆分以後，因為非核心生命周期的主體已經發生變化。主體便可以將這些非核心生命周期分配給其他主體代為執行。這樣，生命周期從時間連續的執行變成了空間上並行，時間上串行的連續活動。

• 新的技術誕生也會導致某些核心生命周期變為非核心生命周期，例如照相機的發明導致了人看到物體的生命周期發生了主體轉變。
  核心生命周期在拆分後，變成了通用服務，最後演變成了一個個職業。而大生命周期變得更加精簡，可以更加專註自己核心生命周期

1.2時間：

• 時間是人們對事物變化的一種度量

• 萬物遵循生命周期規律，隨時間流逝生生滅滅，不因個人意誌所轉移。
  生命無常，雖然每個人個體的生命周期無法按自我意願進行延長。但是，通過提高自身的能力以獲得更多成就，產生對社會更多的貢獻，這是另一種層面的生命的延伸

1.3為什麽產生架構：

• 推動人類社會架構的產生，本質上是人類對於時間無法控制的恐懼。

• 按特點進行分工以後，生產力得到了提升。相對的人的生命得到了一定的延長。

• 實際上按特長進行分工便形成了人類社會的架構。

• 良好的社會架構和分工使獨立的人類節約了為了生存付出的時間。有了更多的精力來幹自己有意願去做的事，或更加擅長的工作。
  讓擅長的人去做他擅長的事，每個人可以專註於自身擅長的事和喜愛的事。

1.4什麽是架構：

• 架構的思考來源於對生命周期的識別，以及對生命周期的拆分。

• 如何定義架構：
  a) 根據要解決的問題，確定問題的主題，界定目標的邊界。
  b) 切分目標的生命周期，區別核心與非核心生命周期。將非核心生命周期獨立起來，使之並行起來，縮短整個生命周期的執行時間。
  c) 對切分後的部分，確定各自的生命周期和主體，以及負責的角色。
  d）在拆分後的生命周期之間建立溝通機制。讓非核心生命周期可以圍繞核心生命周期形成樹狀結構，提供其需要的服務。

• 架構總是在業務遇到瓶頸過程中產生，在瓶頸的解決中應用，在業務消亡時一起消亡

• 自然業務的生命周期就是架構的生命周期

• 每種業務架構拆分是確定的，區別的只是規模不同
  

  架構是為了業務而服務，讓業務更加高效，讓業務更健壯，讓業務更服務於更多的人

1.5架構和樹

• 樹狀結構的增長成本低，溝通路徑增長少，溝通和能量傳遞行好。架構的產生恰恰是為了應對增長，自然而然架構都是樹狀架構的。

• 樹狀結構主次分離，非核心生命周期發生問題不會造成系統性問題。

• 非樹狀的分離不算架構，因為非樹狀結構無法保證架構的權責分離，業務會阻礙增長。

• 架構的目的是讓樹按自己的規律成長，而不是反過來在業務中加入架構自己的材料，幹擾核心業務。

• 樹狀結構的權責對等保證了參與人能從自身工作中獲利，從而保證參與人能夠持續的推進業務的生命周期。
  樹狀結構是架構的必要結構，脫離樹狀結構架構的設計不能應對業務的持續增長

1.6概念

• 概念是人互相溝通並認識這個世界的基礎

• 不同的概念是為了解決不同的問題而產生的。客觀環境決定了概念解決的具體問題。（同一個概念名詞在不同的客觀環境下解決的很有可能不是同一個問題）

• 設計架構時，先去探索概念所解決的問題，才能更加準確的區分核心、非核心生命周期，為架構打好基礎（需求分析的方法論）
  人與人之間溝通的基礎是概念，但是每個人在不同的客觀環境中所成長，所以在對架構的分析和設計中需要先統一概念，才能真正的設計出符合業務的架構

1.7什麽是抽象

• 抽象實際上是把很多不同概念的相似部分合並在一起，形成一個新的概念。

• 抽象是一個分類的過程，根據不同的人或業務抽取出所關心的特征。

• 架構設計者必須要置身業務中，感受業務的個性，認識到業務所面臨的問題。在充分了解個性的基礎上才能談到共性，否則這個抽象只是個人臆想的假共性。
  共性和個性因不同人和業務方向而不同，在抽象共性的時候充分理解個性才能更好的抽象共性，從而設計出更加適合的架構

1.8識別問題

• 核心生命周期才是最主要需要解決的問題

• 識別問題的能力決定著架構師的水平

• 解決問題要克服對時間的焦慮，要先耐心的把問題搞清楚

• 搞清問題先要了解問題是誰提出的，搞清真正的問題是什麽樣的。

• 不分析清楚問題就去解決問題，最後結果是問題沒有被解決。反而，還產生了新的問題需要去解決。
  強勢插入：有時候產品或者需求方直接給出的是問題解決方案。但是，大部分情況下這個解決方案並不能真正的解決他們需要解決的問題。所以就導致了需求重復變更，開發人員不斷抱怨，結果問題還沒解決。開發人員應該盡可能的通過溝通和交流了解需求方的真正問題。

• 工程師在解決問題的時候應該好好思考，到底是在幫誰解決問題。搞清楚提出問題的主體才能找到真正的解決方案。（抱著完成自己工作任務的思想，去處理問題的方式是非常危險的。因為此時問題主體已經變成了“我”，而不是真正需要解決問題的主體）

• 任何找到架構師的問題，都不是真正的問題。

• 發現問題永遠都比解決問題更重要。

• 警惕那些直接提出解決方案的問題，基本上這類解決方案都不能解決真正的問題。 *
  a)這是誰的問題?
  b)什麽問題?

1.9切分的原則

• 所有的切分調整，都是對相關人的利益進行調整。（人個體對利益最大化的追求）

• 在社會上，提供的服務更多更好，就能換取到更多更好的生活必需品。

• 利益才是原動力（引申：相幹人培訓–王直）

• 切分不均衡導致的權責不均衡會導致生命周期無法順利進行

• 切分出來的生命周期不能超過一個自然人的負載（自然人的負載也根據個體不同而不同）

• 切分是內部行為，應該對系統外是透明的（邊界區分）

• 架構的前提是吧一個生命周期連續過程拆分成了一棵樹，因為有了樹才會有層的出現。

• 樹的層次越低，溝通損失越小，效率越高。（管理扁平化）

• 節點能力提升或技術提升都可以幫助減少其子樹的深度。

• 切分的結果最後會體現在組織架構上。
  良好的切分會讓整個業務架構樹茁壯成長，子節點的權責不對等則會導致整個架構受影響

1.10架構與流程

• 流程就是多個角色為了把一件事做好，按時間順序協作並完成的整個過程。

• 流程形式上與生命周期相似，但流程關註的並非生滅，而且多個人如何完成同一個目標。

• 流程是描述整個事物發展各種可能性的樹
  業務為了長大發生了架構拆分，形成了樹。而流程把拆分之後的業務進行組合，通過遍歷樹，重新形成了業務生命周期整體

1.11什麽是架構師

• 架構師要發現問題的主體，挖掘出核心生命周期。合理分配非核心生命周期的職責。根據核心生命周期將工作成功組合起來，達到1+1>2的效果

• 架構師的權責也要是對等的。

• 架構師的工作效果應該由解決問題的效果也就是增長的效果來決定

• 架構師應該是某個業務或領域的負責人，如果置身於業務子節點中，架構的分配方案將難以落地
  人人都是架構師。在生活當中每個人或多或少的都在進行著業務的架構劃分。比如，桌面的擺放，軟件的順序，到達某個點的路線。在閱讀本書的過程後，從霧裏看花，身在此山中的感覺中走了出來。發現架構無處不在，不管是夫妻之間，同事之間，朋友之間。根據不同的主體進行分析，了解他的主要問題所在，或者溝通的要點。將會給生活、工作帶來莫大的幫助

第二部分、軟件架構

2.12 什麽是軟件

1、軟件的目的就是把人類生活的非核心生命周期軟件化、虛擬化，以提供更低的成本和更高效的新生活,讓核心生命周期運行的更加容易，讓非核心生命周期2、的處理更少的占用人類的時間，變相的延長人類生命。

3、成本為王

4、天空才是極限

2.13 軟件的生命周期

1、軟件開發生命周期，軟件運行生命周期

2、人們真正需要的是軟件啟動後為我們帶來的服務，也就是說軟件運行生命周期才是人們真正需要軟件的地方

3、要成為某個領域的專家，需要一萬小時的訓練。按每天8小時計算，需要一個人在一個領域工作滿5年

2.14 什麽是軟件架構

1、要解決什麽問題：業主的問題、計算機的問題

2、分別是誰的問題：業主、軟件工程師

3、分別有什麽問題：利益問題、與業主的溝通問題

4、分析問題：

5、會產生哪些架構：組織架構、樹狀架構

6、軟件架構就是通過對軟件生命周期的拆分，在符合業務架構的前提下，以達到軟件本身訪問增長目的的方式。

7、軟件架構離不開軟件開發團隊的組織架構，這個組織架構是軟件開發生命周期和軟件運行生命周期的執行者

2.15 什麽是軟件架構師

1、具備架構師頭銜的人並不一定是架構師

2、軟件架構師把完成業主的工作當成自己的最大利益，深入到業務中去。

3、軟件的生命周期、業務的生命周期

4、軟件架構師需要去拆分生命周期，並要形成組織架構去落實架構執行，而且要平衡別人的利益，甚至去調整別人的利益。

5、對於軟件的開發生命周期和軟件的運行生命周期，軟件架構師必須要具備權力去調整。這一點要求軟件架構師必須是一個軟件團隊組織領導者的身份。

6、要想做好架構師的工作，就要向大自然學習，這樣才能夠認識到事物本身的生命周期，並能夠去順應事物自身的生命周期的規律來進行拆分，以達到增長的目的。

7、架構師很冷靜、很平等地對待所以的技術，只選用合適的技術。技術人員喜歡熱衷於某種技術，對其他技術嗤之以鼻

8、架構師是技術的使用者。技術本身沒有好壞，因時因地而已

9、架構師拆分生命周期，技術人員實現生命周期。這就是為什麽架構師需要有組織架構的權力，因為要確保架構拆分的落地。

10、技術是架構師手中的工具，當沒有合適的技術時，架構師回去創造技術，或者催生出新的技術。

11、軟件技術、業務技術。

2.16 業務、架構和技術三者的關系

1、什麽是技術

通過人為創造條件，讓指定的規律按照人類的意願發生，這就是技術

所謂業務，就是要解決人類的問題，目的是為了支撐人類自身的生命周期，使人類獲得利益

2、先有業務問題，才會有技術來解決業務問題。而業務的長大要求，提高了對技術的要求，導致了對業務生命周期的拆分，以並行的方式提升效率，形成了架構，也形成了新的技術。

3、重復發明輪子

（1）當技術要解決的問題和拆分出來要解決的問題一致時，這是最完美的。

（2）當技術所提供的能力，遠遠超出需要解決的問題時，往往掌握技術和維護技術就會成為負擔。

（3）當技術所提供的能力和我們所要解決的問題部分匹配時，要判斷是否要采用，最終還是要看成本。

4、開源技術

（1）軟件運行生命周期這部分才是軟件真正的核心能力。代碼的核心在於作者對其理念的實現，而不是代碼本身。代碼的內容反映的是作者對世界的認識，反映的是作者的世界觀。

2.17 軟件開發

1、軟件叠代：優先級、敏捷，犯的錯越多，糾正的越快，就越能減少線上的問題

2、軟件開發的分工：為了組織好代碼，架構師需要去理解業務的核心生命周期以及業務的架構拆分，形成代碼的架構。為了組織好軟件工程師，我們需要把軟件劃分為組件，或者拆分軟件，盡可能的讓軟件工程師之間並行工作，減少沖突。為了組織好軟件工程師，就需要形成軟件工程師的組織架構，與軟件、組件進行對應，與業務的組織架構對應。

3、軟件開發模式：（1）以不信任軟件開發工程師為基礎，以避免軟件開發工程師犯錯為核心的開發模型。大量的文檔，不要求工程師理解，按文檔寫，大量的測試；（2）以信任軟件開發工程師為基礎，以軟件工程師為核心的開發模型。

4、軟件工程師的支持者

（1）軟件架構師要想做好架構工作，首先必須是業務的架構專家，同時還得是軟件的架構專家，這樣才能夠支持好軟件工程師的工作。

（2）架構師本身也是構架師的一個業務，也需要架構拆分，形成不同領域的架構師。

2.18 軟件的架構拆分

1、軟件開發團隊的拆分

（1）多個業務團隊對應一個軟件開發團隊：可能造成多種業務在一個軟件中纏繞

（2）一個業主團隊對應多個軟件開發團隊：產生很多溝通，扯皮，效率低下

（3）一個業主團隊對應一個軟件開發團隊（最優選擇）

2、軟件的拆分

（1）多個軟件團隊開發同一個軟件：代碼容易沖突

（2）一個軟件團隊開發多個軟件：軟件之間的界限變模糊

（3）一個軟件開發團隊開發一個軟件（最優選擇，但似乎不太現實）

3、軟件開發的基礎技術：UED，日誌、流量分流、基礎架構、運維等

4、軟件拆分的第二動力：流量的增長

5、架構不可能一步到位

2.19 如何寫好代碼

1、服務代碼、黏合代碼、儲存代碼，業務邏輯代碼

2.20 單元測試

1、單元測試：單元測試用來測試工程師自己寫的邏輯，比如排序算法這種

2、自測

3、集成測試

2.21 軟件架構和面向對象

2.22 軟件架構與設計模式

1、模式只用來解決共性問題，不要“過度設計”

2.23 軟件架構與軟件框架

1、mvc，orm（hibernate），crm（客戶關系管理系統）

2.24 軟件運維

1、隔離：辦公環境與生產環境， 軟件、硬件、網絡、電力的變更

2、監控變更

3、預警變更

2.25 軟件訪問生命周期

1、用戶--客戶端--網絡--目標軟件--應用服務器--容器（虛擬化）--操作系統

2、集群

3、數據中心：災備、負載均衡

2.26 軟件架構和大數據

要做好大數據，真正的焦點不在“大”，而在“數據”本身。因此我們要先真正的理解數據，才能夠處理好數據，讓數據產生價值。

2.27 軟件架構和建築架構

第三部分、軟件架構的應用

3.28 交易

3.29 產品

3.30 用戶

3.31 訂單

3.32 交易系統

3.33 事務

本文出自 “風之痕_雪虎” 博客，請務必保留此出處http://snowtiger.blog.51cto.com/12931578/1947384

聊聊架構--讀書筆記