什麼是架構？為什莫要進行架構？怎樣進行架構？這三個問題基本可以涵蓋本書全部內容。為什莫我會如此大膽的說——因為這三個問題已經包含了架構的意思，有邊界，有層次，分工明確，這些部分之間能夠進行有機的聯絡，合併組裝成為乙個整體，完成目標的所有工作。這是我對全書的概念與認知路線，下面對第三部分refined architecture階段進行**：
對於什麼是架構？每個角色都有自己的關注點，不同涉眾看待軟體架構的視角自然也是不同的。不過也不是無跡可尋，大致可以從五個角度來劃分：邏輯（職責劃分） 物理（物理節點安排） 開發（程式單元組織） 資料（持久化設計） 執行（控制流組織）。也就是五檢視，每個試圖，乙個思維，一組技術關注。這便是細化架構。
架構最重要的一點，就是它能把難以處理的大問題分解成便於管理的小問題。
就劃分子系統策略，可歸納為3種：
分層的細化：可簡單地概括為mvc模式，模型(model)－檢視(view)－控制器(controller)，它們各自處理自己的任務
分割槽的引入：引入分割槽，以便於支援深度優先的迭代開發
機制的提取：基於具體類的協作則算不上機制、基於具體類的協作則算不上機制、基於介面（或抽象類）的協作是機
制，實現不同的最終功能可以重用同乙個機制。
而劃分子系統的依據4個重要原則：
職責不同的單元劃歸不同子系統
通用性不同的單元劃歸不同子系統
需要不同開發技能的單元劃歸不同子系統
堅固工作量的相對均衡，進一步切分太大的子系統
協作決定介面，"分
"是手段，"合
"是目的，不能合在一起支援更高層次功能的模組，有何用？
設計模式是基礎，要站在各個角度看軟體架構。並且通過質疑「對不對」和「好不好」，可以發現新職責，或者調整協作方式。
結構設計和行為設計相分離。
架構設計不是一蹴而就。需求對架構設計有「驅動」作用，不斷設計中間成果->質疑中間成果->不斷調整完善細化中間成果->繼續質疑->繼續完善…
物理架構思維框架：目標層(xx性
)，思維層
(xx開銷，
xx爭用
)，結果層
(軟體單元
, 資料單元
, 物理節點
, 網路
)執行架構：如果系統中沒有引入並行處理或者併發處理，並且系統也沒有基於sdk，
api等基礎軟體進行定製開發，那就不許要執行架構
執行架構包括：1，控制流
(程序執行緒，中斷的服務
)2，控制流組織
(系統啟動停機 控制流通訊 加鎖或者同步
)確定引入控制流的幾點建議：為了實現節點之間的通訊，通常的做法是引入一條控制流來專門負責，物理架構中每個節點至少有乙個控制流，節點是具有主動行為的裝置，並為其引入專門的控制流，來自使用者或者外部系統的併發訪問，常需要後端服務支援多控制流。在需求一級描述的併發或者並行的也需要引入控制流
一單系統中不止一條控制流，則需要附加工作量(建立 銷毀 建立共享記憶體 訊息
)等不同工作量直接的通訊機制
控制流：是再乙個處理機上順序執行的系列動作。控制流圖顯示了系統中不同控制流之間的關係，控制流的起點是主動單元，它會呼叫被動單元，如此層層呼叫，就形成了乙個控制流。明確了系統中所有的主動單元，就抓住了每個控制流的源頭，從而可以把併發執行的所有控制流程理清楚。
執行架構設計工作只要把握住控制流圖，就能提綱挈領的開著其它設計工作
控制流的常用手段：程序
執行緒中斷的服務
一線架構師實踐指南閱讀筆記
我個人認為,完整覆蓋 需求進,架構出 的架構設計方法才是符合一線實踐需要的。pre architecture就是架構設計的最前期階段,其工作目標包括 理解需求 建立需求大局觀 確定架構設計方向等。磨刀不誤砍柴工 這是近乎常識的古訓。整個admems方法包含pre architectureconcep...
一線架構師實踐指南閱讀筆記2
一線架構師實踐指南閱讀筆記2 第6,7章 concepture architecture 概念性架構 把最關鍵的設計要素和互動的機制確定下來，然後考慮具體技術的運用，設計出實際架構。概念性架構界定系統的高層元件，以及它們之間的關係。概念性架構意在對系統進行適當分解，對高層元件的職責進行了籠統的界定，...
《一線架構師實踐指南》閱讀筆記02
架構 是人們為了提高生活質量，進而為了提高生產力，接著為了提高生產效率，而做出的對目標的有機的分割。這種分割與建築的架構是一樣，對目標內部進行空間切分，又留下門窗與各部分進行連通，讓各部分相互隔離而又可以有效的溝通。就好像我們的社會，我們每個人通過自己的工作掙到錢 分割 讓後通過錢與物的交易 溝通 ...