实际上从比较低且通俗的角度来说，代码模块A和B，如果A模块直接或者间接引用B模块，但是B模块从不直接或者间接引用A模块，这便是A在B的“上层”。
因此在vs开发环境下只要分“项目、工程、模块”都是分层。把那些单纯地脱离实际去卖弄理论名词的东西落地之后才能实用。
如果放在不同工程之中的类型放在（挤在）同一工程之中也是完全可能的，也没有什么不可以，相反则不然。
划分工程，可以从类型之间依赖关系入手，希望不同工程之间类型的关系很少，而依赖比较多、比较明显的类型放在同一工程内部。对于继承关系的类型，很自然地可以放在不同工程中，当然如前所述挤在父类的工程中也可以，这完全是从反映“分析、扩展”的业务模型出发，而不是从计算机编程出发。
在动手之前，拥有设计蓝图，明晰所有类型之间的关系，这是分工程（模块）的唯一条件。
注意，分模块不是分层。分模块更加符合分析设计要求，更加直观地表达模块之间的依赖关系。“管他需要分几层？”，只要分好模块，知道模块之间的依赖关系，“分几层”才确定下来。
对于小型的软件，把别人说的“3层”搅合在一个工程里也许也没有什么；对于大型软件，也许分上二十个工程也觉得不够。
由于系统内部关系复杂，你所采用的开发框架、对系统内部结构的不同认识、用户的“阶段性”修改需求描述、采用的外来模块等千变万化，真正的系统最后会被分几层，是个完全“不确定”的结果。没有看到详细的设计蓝图，谁也不可能正确地说出来。
