系統架構師談企業應用架構之系統設計規范與原則1
一、上章回顧
在上篇中我們講解了幾類UML2.0語言新推出的建模圖形,總體來說通過這些圖形能更詳細的將某類信息表達出來。在這里我們簡單回顧上篇講解的內容。
上圖中已經簡單介紹了上章講述的內容，具體內容請看：系統架構師-基礎到企業應用架構-系統建模[下篇]。
二、摘要
本章將主要的簡單介紹在系統架構中的設計模式及相應規范準則。并結合相應的代碼來說明如何遵循系統架構中的一些基本的設計規范及準則。而我們將在本文介
紹幾類常用的設計規范，我們先來看看結構化設計的二個基本原則：
當然既然提出了基本的準則，那么我們如何來滿足準則呢，并且能更好的設計呢？我們可以通過如下手段來達到這樣的要求：
當然圖中演示了功能分離的策略，通過把需求按照不同的功能詳細的劃分開來，每個功能都是獨立
的，當然我們這里也可以成為是關注點。下面我們將針對這些原則進行詳細的講解。
三、本章內容
1、上章回顧。
2、摘要。
3、本章內容。
4、設計規范及原則。
5、如何滿足設計要求。
6、本章總結。
7、系列進度。
8、下篇預告。
四、設計規范及準則。
1、高內聚
首先我們來看看內聚的含義：軟件含義上的內聚其實是從化學中的分子的內聚演變過來的，化學中的分子間的作用力,作用力強則表現為內聚程度高。在軟件中內
聚程度的高低，標識著軟件設計的好壞。
我們在進行架構設計時的內聚高低是指，設計某個模塊或者關注點時，模塊或關注點內部的一系列相關功能的相關程度的高低。
例如：下單模塊：
一般情況下，下單模塊都會有如下的信息，訂單的信息，產品的信息及誰下的單(買家信息)。這是基
本的，那么我們設計的時候就要把相關的功能內聚到一起。當然這是從大功能(下單管理)上來說，當然這些模塊還可以再細化分成產品、訂單、會員等子模塊。
例如我們在設計數據庫操作輔助類提供的方法有：
通過這樣的方式，那么這個組件只負責數據庫操作。這樣帶來的好處也是顯而易見的。高內
聚提供了更好的可維護性和可復用性。而低內聚的模塊則表名模塊直接的依賴程度高，那么一旦修改了該模塊依賴的對象則無法使用該模塊，必須也進行相應的修改才
可以繼續使用。
低內聚的模塊設計的壞處有：首先模塊的功能不單一，模塊的職責不明確，比較松散，更有甚者是完成不相關的功能。這樣的設計往往是不可取的。可以通過重
構來完善。
下面我們來說下高內聚的簡單解釋：什么樣的模塊算是高內聚，并且能夠在系統中很好的使用。
那么我們在設計的過程中如何去完成高內聚呢？
以上基本上講述了高內聚的好處，并且闡述了如何實現高內聚的步驟和原則。下面我們來說說可能高內聚帶來的壞處。
高內聚有時候也不是說所有的情況都采用這樣的原則，當然高內聚還是要適度的，下面來舉例說明：例如內聚性要求強的話就像Windows32中系統提供的
API，里面的函數太多了，都放在一個Dll中，那么每個函數完成一個功能。這樣強大的功能，會比較復雜，所以并不是完全的高內聚越高越好，還是要看實際的需要。
當然維護起來也不是特別的方便。
2、低耦合
首先我們來看看低耦合的定義：低耦合是用來度量模塊與模塊直接的依賴關系。耦合當然也可以這樣簡單的理解，我想懂電腦的應該都知道，CPU與主板之間的
關系，CPU如果是特殊的CPU必須使用特殊的主板來支持，那么如果說這個CPU不唯一依賴唯一主板，那么就認為這個CPU與主板的關系是低耦合的關系。
下面我們來舉例說明低耦合的設計與高耦合的設計：
這是一個簡單的低耦合的設計，電器與插座之間是低耦合的關系，就算我替換了不同的插座，電器依
然可以正常的工作。因此簡單的描述如下，就是A模塊與B模塊存在依賴關系，那么當B發生改變時，A模塊仍然可以正常工作，那么就認為A與B是低耦合的。
1、筆記本接音響可以正常的使用。
2、筆記本接專配耳機正常的使用。
對應一般的音響來說，筆記本是通用的，音響和筆記本直接的關系是低耦合的，但是筆記本和耳機卻是高耦合的，只有專配的耳機才能和筆記本互聯使用，而不
是通用的，所以說筆記本和專配耳機存在著較強的依賴關系。當然最簡單的方式就是筆記本提供統一的耳機接口，可以滿足一般性的需求。
下面我們將來分析如何構建低耦合的設計。
總結
上面我們已經講解了低耦合和高內聚的二個原則，通過這2個原則我們知道，滿足這2個原則是衡量一個架構設計好壞的一個參考標準。下面我們將來講解通過
功能分離的方式來滿足上面的2個原則。
五、如何滿足設計要求
1、如何按功能進行模塊化的分離。
我們在將一個系統進行功能劃分時，我們一般如下來進行：
首先、我們先把功能職責劃分成獨立的單元。
例如現在有個B2C系統，那么我們按照B2C的需求，如下分析：
我們這里簡單的分析下B2C應該具有的功能模塊，當然這些模塊的劃分中，有些模
塊還可以繼續的分離，當然我這里只是實例分析出來。
2、對分離出來的模塊化進行抽象，例如我們以支付為例。
這里通過支付接口向外提供服務。那么外界模塊不關心支付系統模塊的變化，只需要調用接口
即可，如果具體的支付方式，比如支付寶的方式發生改變，在調用支付服務的模塊中也不需要做任何的修改就可以正常的提供服務。顯然這樣的方式是不錯的實現方
式。
通常情況下我們在系統分離式只是以接口的方式提供服務，供其他的模塊進行使用。在模塊內部有大量的信息是不要向外部暴露的，所以模塊在設計時訪問域的定
義就要劃分好，防止因為訪問域的定義而對模塊的信息造成破壞。
下面我們來看下功能分離在不同的設計理念下都是什么樣的表現：
上面只是實體性的分析了功能分離的好處及應用的廣度，當然我們在后續會結合實例來講解如何來實現這樣的軟件設計模式。當然這只是軟件的架構設計，那么如
果細化到具體的實現呢？我們如何去設計每個功能點呢？這就是下章我們要講解的內容了，那么本文先列出二種常見的方式。
下篇我們將針對設計原則中的實現方式，進行詳細的剖析與具體實現進行舉例講解，希望大家多提意見。
六、本章總結。
本章中主要簡單的講述了軟件設計的二個基本的規范與原則：
1、高內聚：描述了模塊內部的一系列功能的相關程度,對于功能之間相關度不高或者根本沒有相關性的功能包含在模塊中的做法是不可取的。
2、低耦合：描述了模塊直接的依賴、感知程度，耦合的衡量標準是從低到高，一般來說耦合度越低越好。
當然有些特殊情況下，可能這二個原則也有矛盾的地方，當然我們還是要根據項目的實際需要及情況進行抉擇，當然這二個原則是為了設計提供更好的擴展性、
可讀性、可維護性、極高的可復用性，所以要求我們在設計時盡量去滿足這二個基本原則。而幫我去達到這二個準則的途徑就是通過功能分離及細化來實現這樣的準
則。下一篇我們將深入的分析與舉例來說明實現這二個原則的各種規范及準則。
八、下篇預告。
下一篇將會已我們將深入的講解功能分離的設計準則及實現方式，如何在設計中使用設計模式來構建滿足高內聚、低耦合的功能模塊等等。將通過實例化的方式對
每種原則及實現模式進行分析和舉例。如果大家有好的意見和建議可以及時反饋，謝謝您的寶貴意見。
后語
希望看完本章的朋友可以從本篇中學到相應的軟件設計規范，懂的人可以溫習下相應設計準則，本篇希望能夠拋磚引玉，希望大家能夠多提出寶貴意見。由于是本
人平時工作中的理解與總結，不足之處再所難免，還請大家批評指出！如果您有什么意見或建議，請多多提出！大家的支持就是我的***動力！
作者：CallHot-何戈洲
出處：http://www.cnblogs.com/hegezhou_hot/
關于作者：專注于微軟平臺項目架構、管理和企業解決方案。熟悉設計模式、極限編程、架構設計、敏捷開發和項目管理。現主要從事WinForm、ASP.NET、等方面的項目開發、架構、管理工作。如有問題或建議，請多多賜教！
【編輯推薦】
