這應該是每次我們打算使用模塊化框架來創建新的解決方案或者將已有程序重構時首先面對的一個問題。
這里我們不談詳細的需求與功能點的探討過程，直接拿假設的功能點作為討論基礎。比如我們現在准備實現一個簡單的B/S的留言板程序，它需要如下功能
1） 留言信息展示
2） 增加留言信息
3） 管理員登陸
4） 管理員回復、刪除留言
傳統的三層架構划分大概是這個樣子，一種典型的橫向划分。你可以將他們放在一個解決方案里完成並發布 
現在我們來看看，如何將他們拆分成OSGi.NET所推薦的模塊方式。注意這里是物理和邏輯同時進行划分，可以說是一種“縱向划分”，縱向划分的好處就是可以將相同邏輯的單元組合在一起，成為一個單獨的層面（Aspect），以適應未來的需求變化，替換或者升級
上面只是第一次拆分，主要是將每個功能點的表現層和業務邏輯層整合在一起，數據訪問層可共用一個。接着我們再做第二次拆分，針對是表現層和業務邏輯層
上面拆分完畢后，業務邏輯被分成了兩個獨立的部分，各部分之間是邏輯隔離的且無依賴。我們再繼續划分，這次針對的是表現層，表現層也是經常變化的一個點，尤其對Web來說。我們假設網頁的UI是典型的上下兩層設計，上面是鏈接，下面是具體的內容，如下圖所示
我們可以將這種布局抽象出一個單獨模塊，如下
這樣的划分大致已經達到OSGi.NET的要求了，當然還可以更細致的划分，比如兩個業務邏輯模塊和數據訪問模塊都以“服務”的形式出現，則可再次划分為服務的“接口”模塊和服務的“實現”模塊。最終划分效果如下
更細致的划分我們就不再討論了，可根據實際需要來做進一步處理。
物理的划分和邏輯的抽象是同一個道理，就是為了“封裝變化”，只不過具體的表現形式不同，前者為一個物理文件夾，后者則為一個邏輯單元。但在實際情況中，物理和邏輯划分是同時進行的，物理划分大多時候是以邏輯划分為基礎的。
既然是封裝變化，那我們來看看這種划分如何來適應變化的
1） 如果要更改界面UI，只需要替換“界面布局”模塊即可，當然表現層的四個模塊也應該有稍稍調整，所以更好的方式是他們也需要有個“具體內容”的抽象UI模塊，這里留給大家去研究
2） 如果要更改業務邏輯，則只需要替換兩個模塊的邏輯實現即可，同理，對數據訪問來說也是一樣的替換方式
原文：https://www.cnblogs.com/shalahu/archive/2013/03/20/2970797.html