在軟件高層設計中，如何分解模塊是首要考慮的問題。目前業界公認模塊划分要按照“高內聚，低耦合”的原則來進行，那么如何划分才能滿足“高內聚，低耦合”呢？下面來對模塊分解原理方面進行一些探索，有考慮不周和不成熟之處還請大家不吝指正。
模塊是按功能來分解的嗎？
許多人可能有過經驗，面對一堆功能性需求，多個不同的需求可能要放到同一個模塊里，而某個需求又需要分解到多個模塊里去實現。
比如一個詞典軟件（類似金山詞霸的軟件），通常有查詢詞典的功能需求和添加用戶詞庫的功能需求，顯然不可能簡單地為這兩個功能各分解一個模塊。查詢界面和添加用戶詞庫的界面處理部分會被划成一個模塊，而對詞典的數據管理（查詢，添加等）部分會被划分成另外一個模塊。
通過對以上詞典軟件的模塊划分的分析，可以得出模塊並不是簡單地按功能來划分的結論，因此按功能來分解模塊並不是一個任何情況下都可行的方案。
模塊按專業領域進行分解
仔細觀察上面所說的詞典軟件的模塊分解就會發現，所划分的兩個模塊屬於不同的專業領域，一個是交互領域（圖形界面），另一個是數據管理領域（數據結構與算法）。這樣看來模塊划分是按專業領域來划分的了，是不是所有的模塊划分都是或者應該按照專業領域來進行划分呢？
通過觀察大量的軟件的模塊分解情況，其實可以發現絕大部分模塊都是按照專業領域來分解的，這些專業領域包括軟件公共領域的各個子領域，軟件所處理業務的專業領域及其子領域等。
軟件公共領域常見的子領域有數據結構算法，圖形界面，IO處理，網絡通信，數據庫，加密，安全，圖像處理，數學算法等，當然這些子領域還可以進一步划分出更小的子領域來。
軟件所處理業務的專業領域則是指具體的業務方面所屬的專業領域，如財務軟件的業務包括了財務專業領域，CAD軟件業務包括了機械制圖方面的專業領域等。
這些不同專業領域內的內容都是被划分到不同的模塊里，沒有人會在同一個模塊里同時實現網絡通信和數據結構算法的功能。這樣可以得到模塊分解的一個最基本的原理：
模塊分解基本原理：不能在同一模塊中實現兩個不同專業領域的內容
上面這句話的意思其實和模塊按專業領域進行分解是一回事，只不過意思更明確一些。注意這里說的是“實現”，有許多的模塊中需要用到許多不同專業領域的接口來進行處理，即在同一模塊中可能會調用許多不同專業領域的接口來進行處理，調用接口並不屬於“實現”。
模塊按專業領域來分解只是一個原理，無法證明它的正確性，因此看一下它會不會與已有的一些設計特性有沖突呢，比如常說的“高內聚，低耦合”，可復用性，可擴展性等是否會產生沖突。
推論1：按專業領域分解的模塊是“高內聚，低耦合”的
為什么說按專業領域分解的模塊事“高內聚，低耦合”的呢？專業的划分都是人們經過長期的實踐和探索划分出來的，專業領域本身就是“高內聚，低耦合”的， 比如數據結構算法專業和網絡專業耦合就很小，但每個專業的內部都是高內聚的。
推論2：按專業領域分解的模塊是可復用的
這點很容易理解，模塊按專業領域分解完后，顯然任何兩個不同的模塊都不會有重復的內容，因此滿足可復用的特性。
推論3：按專業領域分解的模塊是可擴展的
當有新增需求時，只要將新增需求分解成各個專業領域的內容，新增的內容可以分為三類：
1、在已有模塊里已經有對應的實現，
2、屬於已有模塊的領域，但是沒有對應的實現
3、不屬於已有模塊的領域
對第1種情況中，顯然不需要對已有模塊做任何修改和添加；對第2種，需要在已有模塊里添加相應的接口來實現對應的內容；對第3種，需要增加新的模塊來實現對應的內容。
所有這三種情況，都符合軟件設計中的可擴展特性，因此按專業領域分解的模塊是可擴展的。
推論4：按專業領域分解的模塊是可維護的
這點可以由由模塊高內聚，低耦合，可擴展性的特性得出。
由此看出模塊分解基本原理是和以往對設計的要求是相符合的，但是會不會有反例呢，我實在不能確定，因為這個原理是無法證明的。如果有人發現有不應該按照專業領域來分解模塊的反例，請回復一下。
模塊按專業領域分解的困難之處
雖然模塊按專業領域進行分解看起來好像很完美，可以說絕大部分需求都可以按照這個原則來進行分解。但是並不是說就不存在問題了，實際上按專業分解的前提條件就是要將需求能夠分解成已有專業領域的內容。
困難1：如果需求的內容屬於新興未成型的專業領域的內容，那么按專業分解就不是那么容易了。
困難2：許多需求最終需要分解到某個專業領域的某個子領域里來處理，而很多專業領域還在發展之中，它的許多子領域還沒定型，這時划分模塊也不是一件容易的事情。
