这应该是每次我们打算使用模块化框架来创建新的解决方案或者将已有程序重构时首先面对的一个问题。
这里我们不谈详细的需求与功能点的探讨过程，直接拿假设的功能点作为讨论基础。比如我们现在准备实现一个简单的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