物理分层（分工）：按代码职责划分，目的是重用代码，提高效率，很显然，代码被分的越细越好。我们把最底层的代码称为原子代码，然后一层层收集分类，这样在不同的粒度上都是按强内聚原则装配的，所以物理分层的数量并不固定，最典型的物理就是：BLL、DAL、MODEL。论坛里很多人的思想仅仅停留在物理层面，物理分层是基础工作，或者说是比较原始的代码策略。物理分层不负责降低耦合，相反，往往把代码之间的关系搞得像一团乱麻，整个架构经不起一点风吹草动。
逻辑分层（协作）：为了解决物理分层带来的副作用，按依赖或驱动关系划分，为了更好理解这种关系，我们可以把它称作：分级。很显然，层级越少越好，目的是降低耦合，比较理想的逻辑分层是星形结构或者说总线结构，最典型的逻辑分层就是：MVC，逻辑上就是2级，而且与物理分层的原则类似，在不同的粒度上，都是可以做到2级的，比如ASP.NET MVC就是解决UI的，你也可以在全局上MVC：程序代码和数据库是V，项目模型就是M，开发工具（通常指团队自主的开发工具）或者将M转换成V的手段就是C，所以如果你能这样看待开发全局，就会意识到数据库驱动的开发是多么的不妥了。总之代码之间的逻辑层级关系越简单越好。
其实，最好的理论教材在我们身边无处不在，别的不说，就是我们天天使用的电脑，软件开发的最深刻理论就在里面了，随便举个例子：V：显示器、打印机等输出设备，它们是数据无关的（它们不知道要呈现什么东西）、领域相关的（比如分辨率不同、用途不同），它们并不知道M的存在，他们仅提供接口供C（主板）使用。
需要强调的是，分层在开发全局中只是相对简单的工作（V），最重要的工作是如何转换（C），通过这一步才能控制代码量极限和迭代极限，细节另作探讨。
最后要说：分层是一种实践技能，就像学驾驶一样，没有人上完理论课就学会开车的，对于没有经验的开发者，都要通过不断实践、走弯路、甚至碰壁才能真正掌握。