首先来个大图，增加下感性认识：
这个分层主要以解决方案文件夹来实施业务模块区分。
Client下有两个项目，一个是不可缺少的Website，另一个是本项目向其他平台提供服务的接口所在（当时为另一Java项目提供服务，当时的ＷＣＦ似乎还处于婴儿期吧）。在Ｗebsite那层Ａpp_code下有个ApplicationBasePage.cs类，所有增加新Ｗeb窗体均继承此类，此处提供公共的一些动作。关于那个Common/Javascripts,Common/Usercontrols一看就明白的，不用多说了。
在Ｃore解决方案文件夹下，主要放置整个项目可以公共利用的一些操作。从图中看出主要区分为Enums/.Exceptions/Utils根据需要可以再添加即可。在用到之工程中引用此工程DLL即可。注意此处BaseEntity.cs，整个项目中所有实体类均要继承此类。此处为空，在实际需要的时候可以加入内容。
解决方案文件夹DE下就是所谓的分层所在了。其主要是以一个大业务模块来划分的。按图所示，意思很容易明了。（注：解决方案文件名DE与其下小业务模块文件夹名DE仅仅重名，别无它意）。
在BusinessLogic层处设计采用了Ｆacade模式，从图中可出，任何一个Service均有一个接口定义类和具体实现类。并按DefalutImpl来分开两者。对外只提供Ｉ***Facade的接口定义，隐藏所有Service的具体实现。
关于Common层从图中可以看出，无外是模块下”常量”放置处。根据各文件夹分类即可。在实际开发中，除Enums和Ｕtils需要自己人工书写，Ｅntities，BizLogEntries和Exceptions均由工具按规则生成。
数据层DataAccess只存放各个实体类的数据操作。无任何其它放置。
InnerInterfaces是为解决各工程间可能会导致循环引用的问题而增加的。将向外提供服务的接口在此定义，任何用到此服务的工程引用此工程即可。（循环引用的问题当时困扰了好久，后来由研发事业部同志改进了开发插件才解决此问题。）
因现在开发都是团队协作开发，这样分层，各人负责各个功能模块，代码的签入签出不会影响别人，而且编译单元自己控制，不会出现多人编译同一工程引发的冲突。这在大型开发团队中非常重要。