13

其中的關鍵核心點是，不同涉眾的關注點的分割。我有我自己的關注點，你有你的關注點，不同的關注點匯聚到一起，而關注點背后代表的是一種人的觀點，這些人就構成了不同的涉眾，然后在不同的涉眾里面，他們之間會有一些各種各樣的關系，這些關系之間是如何交互的，這就構成了一個模型。

其實，模型是用來表示，各個涉眾，各個關注點，以及他們代表的事物之間的關系的。

對一個觀察者來說，他觀察了一個主題，或者一個物體，一個subject，而這個觀察者他觀察這個主題的時候，肯定是想了解清楚這個主題，搞清楚他要觀察的對象是什么，他要解決的問題是什么。作為觀察者，他之所以去觀察，一定會有一個問題來引導他去觀察，或者說，對觀察者來說，他想回答這個問題，所以他才關注這個問題，他的目的就是想得到的答案。

我們可以使用一個模型，來描述這個觀察者的一系列過程，而標識它的這個過程肯定不僅僅只有一個模型，但我們使用的模型，是抽象了主題里面的所有東西的一個模型，這也就是該模型是一個主題的模型，這個時候，才盡可能的表達出真實的意圖，從而能夠把誤差控制在可以接受的范圍之內。

14

然后，這個Model，這個M就是這個模型的觀察者。

我一再強調，所有的模型不可能完全代表事實本身，它一定是和事實有偏差的，甚至是有些誤差的，在這個模型內，描摹真實世界是不可能的，這個數值內任何數據都有誤差，模型的好壞，不在于消除誤差，而在于是否可以滿足在可接受的誤差范圍之內。

其實對于大部分工程過程來說，尤其是對于整個軟件的開發來說，大多數下，都可以歸屬于是模型驅動的軟件開發過程。

通過模型驅動的軟件開發過程，然后我們最終獲得設定的戰略設想，然后把這種設想，做成了一個模型。所以說，架構它的思想的表達方式，就是去設計模型，設計出能夠表達我們戰略設想的模型。

然后讓我們通過模型，表達出了人、事、物、規則之間的關系，我們的架構最終導向到模型驅動的架構，然后我們能通過使用模型驅動的架構，來驅動我們的軟件開發過程。

15

當然，就概念上來講，軟件架構，并不僅僅只有模型驅動的架構。

模型驅動的架構，也只是一種架構的風格，風格有多種多樣，選擇不同的架構風格也是要看不同的企業環境，我們之所以選擇模型驅動的架構來描述，這也只是為了更好的表達架構思想而已。

架構的風格是為系統的架構信息提供戰略設想的。

這個設想的第一步就是，先想清楚一下我們的風格是什么，再去選擇哪些架構的風格，甚至是需要你去創造架構的風格，而我們最終選擇了模型驅動的架構風格。我又融入了很多的概念，你可以把它當成一種世界觀一種方法論，我們另外選擇的是，面向對象的一種架構的風格。比如，CS（客戶服務器結構），這都是我們架構的一種風格，你一旦了解清楚了需求（requirements），要做的一件事情就是，來選擇一種風格，來有效的設計你的需求。

怎么選的架構模式，當然不是憑空設想，而是腳踏實在，也不是隨機胡亂的組合，而是政治、經濟和斗爭的結果中間尋求的一種平衡，然后根據這個平衡，再選擇這樣一種架構的風格。

16

高度決定我們的視野，你只能站在這樣的高度上，在充分理解了你的環境以及上下文之間的關系上，然后再去發現，分析，與解決問題。

用我們的話說，我們不同的人，因為層次不同，所看到的世界也是不一樣的，這是因為他的關注點不同造成的。

而架構，在一個軟件項目中，是在最高級別在思考與設計，考慮這一系列問題的。它一定要關注一些很多很多互相關聯的事情，一定要對不同涉眾者的關注點的分割，也就是說，一個總裁的關注點肯定和一個員工的關注點是不一樣的，這里并不是歧視不同的員工，當然總裁也是員工，而是說，人在企業中的身份與分工，必定會導致他們看待問題的角度是不一樣的。

換句話說，我們要通過不同涉眾的角度的不同，來區分與分隔這些關注點。

架構師，在一個項目組里，他是一個team的成員，當然有些項目比較簡單的話，也不需要架構師。當你們項目中有架構師的時候，祝賀你，這說明你們的系統比較先進了。因此，架構師是一個系統的設置。

17

關于系統的質量問題，我們分成兩部分，一個是開發時的質量，一個是運行時的質量，設計模式這個可以解決一個重要的quality，那就是軟件開發的質量。質量本身就包括可擴展性，這可以通過設計模式的方式來很好的表達。

我們簡單的介紹幾個設計模式的原理。

(1)、開閉原則（Open Close Principle）

OCP就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。為了使程序的擴展性好，易于維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類，后面的具體設計中我們會提到這點。

(2)、里氏代換原則（Liskov Substitution Principle）

這是面向對象設計的基本原則之一。任何基類可以出現的地方，子類一定可以出現。

LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。LSP是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以LSP是對實現抽象化的具體步驟的規范。

(3)、依賴倒轉原則（Dependence Inversion Principle）

DIP是開閉原則的基礎，具體內容：針對接口編程，依賴于抽象而不依賴于具體。

(4)、接口隔離原則（Interface Segregation Principle）

ISP使用多個隔離的接口，比使用單個接口要好。還是一個降低類之間的耦合度的意思，從這兒可以看出，設計模式就是一個軟件的設計思想，從大型軟件架構出發，為了升級和維護方便。目標是：降低依賴，降低耦合。

(5)、迪米特法則（最少知道原則）（Demeter Principle）

DP是，一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。

(6)、合成復用原則（Composite Reuse Principle）

CRP是盡量使用合成/聚合的方式，而不是使用繼承。

這些原理，都是概念的載體，就是怎么樣才能達到我們的可擴展性，例如可以通過某個具體的設計模式來提供一種做法，但前提是，要了解這些設計模式適用的情景，也就是你要搞清楚你想要干什么。

18

我們的架構框架，要解決一個首要的問題，就是誰來使用你的軟件。

你要找出來系統的涉眾。每一個涉眾都有很多，所以要進行分割。分割出來的結果就一個關注點。

一個涉眾，通過不同關注點構成一個集合，不同的集合根據匯總與綜合，根據業務的特點，我們把它做成一個模塊，然后這些不同模塊互相配合，構成了這樣的一個軟件系統。

我們的系統，有不同的涉眾，有不同的關注點，不同的集合，不同的模塊，就相當于每個人都有自己的事業，而涉眾就是一個人對應的關注點。因為每個人的關注點是不一樣的，而不同的涉眾都有他的利益點，或者說都有他自己的看法，因此不同的涉眾，他擁有的關注點就會不同。

我們架構師，就是通過抽象來分析這些關注點，然后給它取了一個名字就叫涉眾。不同的人就需要有不同的涉眾，然后又對應不同的視點，這些不同視點又組成了一個完整的整體。

所以我們必須要定義不同視點，以及視點之間的對應關系，也就是要確定不同的規則、議事，各種人事物，責權利的規則，這都要理解清楚，這我們前進的目標，不然，你也沒法進行工作了。

很多軟件相關專業的學生，在他們的大學課程里，項目管理、需求分析等等都學了，但去公司里工作時發現沒用，這是因為全是書本上的，沒有實踐經驗，完全是理論，這基本等于沒學。因為，在真實的企業里，不但有技術因素，還有經濟因素，當然還有政治斗爭因素，我會告訴你這就是現實，我們不需要解釋為什么這樣。

企業里面，對剛畢業的學生來說，就是個初級新手，你就得接受這樣的環境，要不你就離開，廟小裝不下大神，走人吧。因此，為了模擬出現實的真實性，我們必須弄一個真實的商業系統，把理論和實踐融入到系統的架構過程中，這可以很好的體現出我們的思想路徑。