接上回。在架構活動中，從收集需求→多維需求ADMEMS分析→重大需求獲得概念架構→魯棒圖分析 →分層分割槽模組，我們很自然的就來到了細化架構的階段。

    在細化架構中，主要要解決架構具體化的問題，目標是形成開發的指導性基礎，大專案要求能指導多個團隊進行並行開發。這個步驟具體是通過一系列不同角度的檢視，去驗證，去敘述，去設計每個子系統檢視中模組和模組的關係。粒度的粗細應該介於高層架構（確定子模組和子模組之間的關係）和實現，模組設計之間。在這個階段中也要關注非業務需求，比如效能。通過這個階段的設計，架構設計就基本落地了。

    細化架構設計的多檢視：包括邏輯檢視/物理檢視/執行時檢視/開發檢視/資料檢視，各自從不同的方面反映架構。

    1）邏輯檢視：包含系統職責的切分，邏輯層，介面，模組，子系統的切分及其互動研究，個人認為在Coding前的必經之路。

    2）執行架構：包含系統一些關鍵核心功能的執行控制流設計，程序/執行緒任務排程， 鎖的設計。個人認為這裡是對系統時序複雜的地方的解析。

    3）物理架構：包含系統物理層的設計，即配置設計，節點和計算資源的分配。

    4）資料架構：包含系統資料儲存的設計，指資料庫配置的策略，不是指資料庫/表設計。

    5）開發架構：包含原始碼的組織和配置設計。個人認為對於成熟的開發團隊，這一項的作用不是那麼重要。

    2），3）,  4)在網際網路服務中使用比較多，對於本文的CAD工具例子，重點講一講邏輯架構，順帶講一講資料架構。

    架構方法實踐 - 客戶端CAD工具範例 (二 概念架構部分) 文中末尾從魯棒圖推演瞭如何將分層，分割槽帶入邏輯架構，另外再補充一點，將公共的部分分離，形成機制。機制是什麼呢？Grady Booch 在他的著作中指出:機制才是設計的靈魂所在......否則我們就將不得不面對一群無法相互協作的物件,它們相互推搡著做自己的事情而毫不關心其他物件。基於介面(和抽象類)的協作是機制,基於具體類的協作則算不上機制。機制是隱式的可抽取的重複程式碼。

       我們可以將前文中的簡單分層，分割槽圖細化為詳細的邏輯設計圖，輔以機制萃取：

    邏輯上工具分為5層，分為檔案讀寫/物件實體/演算法/控制器/GUI 5層，檔案讀寫包括DXF的讀取，Template circuit資料的儲存。實體層代表記憶體中儲存的物件，需要支援2D顯示，編輯，比如DXF的常用物件，也包括Template中的物件，比如圖層，模板引數等。演算法層包括Template處理演算法，構建點線弧圖元為多邊形圖元的演算法以及Circuit Design中的物理連線等演算法。控制器層包括Template資料操作，編輯，選擇等工具。GUI層則是各個功能點的展示。另外，也抽象出幾個機制：幾何繪製，幾何實體編輯，構建多邊形，回滾等等，這些都是抽象物件間的互動，可以抽取出來。

    到這裡，邏輯的細化架構可以說落地了，下面還需要：

    1）對每個子模組驗證，通過質疑提出問題，並驗證。通過數次修復邏輯錯誤和驗證的迴圈尋找重大的缺陷。

    2）對時序上可能複雜的地方重點分析，如果需要，進行執行時檢視的分析。

    3）拆分模組，估算工作量，開發。

    由於這個客戶端CAD工具沒有需要詳細分析 物理/執行/開發/資料 檢視的細化架構，這裡略去。

    最後，個人認為資料分佈方案也是架構的難點，資料分佈方案可以分為獨立schema（每個app使用獨立的資料庫）, 分割槽（根據使用者地點或欄位拆分資料庫），集中（所有app共用資料庫）複製，子集，重組資料等幾種配置方法，在可靠性，可伸縮性，可管理性，資料一致性，通訊開銷上各有勝負，要根據情境和需求進行選擇，具體可以找尋資料深入研究。個人水平有限，希望和大家共同學習。