首先我們講一個故事，盲人摸象的故事。
全國出現了第一個大象，盲人們去摸它的時候，如果盲人摸到的是大象的屁股，那盲人就會說這個大象就像一個繩子；如果盲人是摸到大象的腿，那就會說大象像一個柱子；如果盲人摸到了大象的鼻子，那就會說大象像一個花灑。
可以看出，盲人摸了不同部位得出來的描述結果是不同的，其實描述都是一個一個的觀點view。這觀點view其實沒有對與錯，因為它站在某一個角度去看的，它是對的，但全域性來看，它就是錯誤的。所以，角度在我們架構設計裡面叫做視角viewpoint，這是一個很關鍵的一個詞。我們所有的觀點，也就是所有的架構圖，所有的架構文件，其實都是為了描述這樣一個大象。但是，大象是立體的，是鮮活的，你必須要透過不同的視角，進行切片才能把它描述完整。
如何能完整描述出系統的整體架構，避免盲人摸象，還得用到立方體模型法。從圖中可以看出功能與執行是兩個重要的視角。
功能型模型通常分三步
模組定義
模組可以叫component，也可以叫module，提到模組大家一定會想到低耦合高內聚。我們可以把內聚分為功能內聚、順序內聚、通訊內聚等。我們在做設計的時候，儘量傾向於功能內聚，就是模組內部的所有的功能全都是功能內建。系統是高內聚，而不是偶然內聚，那這樣的設計出來的模組或者這樣切分出來的模組，才更加有效，有意義。
有了內聚，當然就少不了模組間的耦合。耦合也分為非直接耦合、資料耦合、標記耦合等。系統設計的時候，儘量採用非直接耦合，實在不行就採用資料耦合的方式，這樣可以讓模組和模組之間儘量比較鬆散。千萬不要讓模組之間內容耦合，這種高密度的緊密的耦合方式，
透過以上內聚和耦合的定義，基本上我們大概能想象出來模組設計應該怎麼的形式更合理。
模組劃分粒度
採用什麼樣的粒度設計才能實現高耦合低內聚呢，我們可以借鑑DDD的思想（如圖）。
粒度是從左往右是越發細，本來很粗粒度的系統，從左往右逐漸細化為具體的實體與值。但是，也要考慮到在這個劃分過程當中，架構設計的時間也是越來越長了，劃分得越細，設計得越精細，所花費的時間越多。綜合考慮，可以從“子系統/子領域”開始設計，架構不適合涉及太細，大概到子系統/子領域這個級別就可以大概劃分出系統應該劃分什麼樣的模組了。再進一步，我們可以把子系統裡面的內容再劃分成一個一個的微服務，一個微服務可能會對應一個一個的used model裡面一個一個用例，但是每個微服務又是放在一個子系統裡面。所以，可以把一個大的應用劃分為，五個到十個或者二十個左右的子系統，甚至更多。子系統裡面再去劃分為兩個、三個、五個甚至更多的小的微服務。
這樣基本上已經能把一個專案的所有涉及的粒度就達到要求了，不需要去考慮資料聚合，不需要去考慮實體的對應的關係，基本上這樣的層次，已經滿足立方體從需求到功能，再到執行的整體設計要求了。
整體架構草圖AOD
當case model需求圖和system context diagram系統上下文圖都清楚了，接下來就是按照你熟悉的方式把架構圖畫出來。畫圖第一件事不是去畫很詳細的模組，也不是把模組拆分得非常漂亮，而是手畫一張架構設計草圖。如下圖：
這種圖是怎麼快怎麼來，它也是架構設計的核心圖，你可以在後續過程中不停地把新的內容補充進去，重新去更新它，但是第一次畫的時候儘量快，儘量方便，
