User Interface即UI层：该层作为数据输入和展示的界面，是与用户交互的有效途径，所以它起着至关重要的作用。往往给人第一印象的就是UI层，在设计的时候也要根据不同的技术或者不同的要求进行斟酌。通常可以把UI分为B/S UI、C/S UI以及WEB服务。在这里就是我们的ASP.NET项目。

02，WebModelCommon：这层作为UI与领域逻辑的中间层，它的充当了桥梁、筛选、过滤和验证的作用。它主要包括两个工程，WebHelper主要提供给UI一些常用操作。WebLogic主要对UI与领域逻辑的数据进行转换、筛选、验证及过滤操作。

03，Business Logic：Domain Model （Data Model Layer）始终是应用程序的核心，必须投入大量精力，按照面向对象的分析和设计 (OOAD) 最佳做法进行设计同时按照OOP进行开发。

04，FrameWork：主要包括数据访问框架、通用权限框架、异常和日志处理框架、IOC框架、AOP框架等基础或常用功能。

05，SOA：这一层不是必须的，根据项目的具体情况进行取舍，如果业务比较复杂且交互项目繁多，那么SOA可以减轻我们的负担；如果业务比较单一且相对简单，就可以直接调用或者使用Web Service/Remoting/WCF作为通信框架即可。在实施SOA的过程中，可以自己使用WCF+WF搭建一个小型轻量级的SOA框架，也可以使用诸如Biztalk等软件。

06，Reference：这里主要包括第三方的框架和组件项目，把这些文件分门别类地集中放在此目录下。

07，Solution Items：项目的规范、流程、重要文件等。

08，Test：这里主要放置测试需要的一些信息，如测试版本、测试文档等。

09，Publish：这个文件夹主要放置发布的版本。

作者的获奖感言：比较关心有没有奖品？ 其实这个架构比较复杂一点（考虑到经常扩展和升级），如果小项目，就没有必要这么折腾了。当时是支持多国家、多设备，比如同样的项目可以在新加坡和美国根据IP的不同来自动寻址访问，同时根据设备的不同而又有两套路径，手机用户导航到手机网站页面，PC用户就到正常页面。关于数据访问层，有一个适配器，可以通过配置选择ORM（自己写的一套类库，封装在Framework里面）还是经典方式（SQL和存储过程等全部单独写在XML文件里面，通过读取XML文件进行调用，这样维护和版本升级比较方便，同时为了降低系统的负载同时提高用户的响应能力，我们采用了MSMQ和SSB来组织消息队列）。另外数据层都有Mock data for testing，这样就能保证项目扩展和升级造成的相互依赖而耗费过多的时间和精力。如果有时间，可以写一篇文章出来大家探讨！

回复感言：

奖品是必须的，针对此架构写一篇详细的文章，并附上源码。

小项目确实没必要搞这么复杂，可以参考帖子里的“土鳖实战派”，那个分层我觉得就挺实在的。

Mock data for testing是个好办法，有空介绍些好的Mock框架。

最佳吐槽奖： [秦时明月] ！！！

他只在评论里淡淡的回复了一句：“其实我只想说一点:大家都乱了.”。轻轻的来，不留一片架子。不过弦哥是不会放过他的......

于是乎弦哥到他的博客异地远程联网技术 - 博客园里搜刮了一番，发现了他其实也有架子，“Moon.ORM”,“Qin.Data”（和秦时明月这个名字遥相呼应，文艺青年哈）......

其实我想说的是， 无论是所谓“大道至简”的秦时明月，还是主流的圣殿骑士，单从技术实现来说可以说条条大路通罗马...无所谓对错...

但在现实中圣殿骑士的路子可以上的台面去企业做培训，而秦时明月可能更多的是孤芳自赏，其中缘由，大家可以探讨...

阴沟翻船奖 Artech：

作者描述：我在《WCF全面解析》中的一个实例的解决方法结构，基本思路是：先模块（这里指粗粒度模块，可以看成子系统）（两个业务模块：Products、Orders，一个非业务模块：Infrastructure），后层次。 Products.BusinessEntity：提供的业务实体（Business Entity）类型的定义。一般来讲，业务实体和数据契约是不同的，在这里为了简单起见，我们不仅仅将二者合一，还将业务实体作为ASP.NET MVC的Model使用； Products.DataAccess：数据访问层，在这里单纯地提供对数据库的访问了。该项目具有针对Products.BusinessEntity的项目引用； Products.BusinessComponent：也可以称为业务逻辑层，真正的业务逻辑实现 在这里。该项目具有针对Products.BusinessEntity和Products.DataAccess的项目引用； Products.Service.Interface：WCF服务的契约接口定义在这里。该项目具有针对Products.BusinessEntity的项目引用； Products.Service：用于定义实现了上述契约接口的服务。该项目具有针对Products.Service.Interface 、Products.BusinessEntity和Products.BusinessComponent的项目引用； Products：为本模块提供基本的功能，不仅仅包含对服务的调用，也包括一些必要的逻辑处理。该项目具有针对Products.BusinessEntity、Products.Service.Interface和Products.Interface的项目引用； Products.Interface：模块提供给其他模块的服务接口。该项目具有针对Products.BusinessEntity的项目引用。

点评：Artech算是园子里的大佬，貌似还出了书，不过发的这个架子有点出乎我意料，存在有一些值得商榷的问题：

1.从架子中的命名和大体结构明显看出是走的DDD,在DDD中数据访问的具体实现(就是夹子里的DataAccess)应该是放在基础设施层（就是夹子里的Infrastructure），而Artech却貌似只把Infrastructure作为了"非功能性需求"的Framework去用。并把Infrastructure叫“非业务模块”，显得有些外行....

2.Products.BusinessComponent业务逻辑层 直接引用了Products.DataAccess，这也是个严重的问题，如果DataAccess是没有接口的，那么业务逻辑层依赖数据访问层，在DDD和马丁大叔的企业架构设计中，是一个反模式！！！，如果DataAccess里有接口，那么，DataAccess的接口应该是放在业务逻辑层的，然后通过依赖反转去用，而DataAccess的具体实现是放在Infrastructure里的。

3.如果没有用WCF，那么我认可可以省略掉DTO，但架子里上的WCF,还把DTO和PO合二为一，这个我非常不赞同。

4.Products层和Products.BusinessComponent层边界不清晰，按Artech描述 ，两个层里都可以放业务逻辑，但描述的模棱两块。而且基本可以看出Products.BusinessEntity又还是失血模型，这个设计完全让人摸不着头脑。Products层我猜是有点DDD中Application层的意思，但Artech明显做的不对。

总之我感觉这个架子，装的成分比较大，思路十分不清晰，命名很不规范，有失水准。

作者的获奖感言：谢谢给我这个奖：） 1. 我的这个结构主要考虑的是模块化，而不是层次化。或者在模块的基础上划分层次。 2. 模块是以功能为主，模块封装业务功能和非业务功能。我主张在模块级别对外提供服务，而不是层次上对外提供服务。 3、层次是模块为了实现自身功能而进行的层次划分，所以没有必要为每一个层次定义接口。DataAccess提供接口的一个很大的目的在于隔离数据存储，是对多种数据存储方式的支持。实际上很多类似与DbHelper就能够提供这样的功能。所以我很不喜欢为DataAccess定义接口，虽然PetShop是这样做的，很多项目也是这样做的，我依然觉得很丑。 4、接口是是契约，是“服务”的接口，只有在对外提供服务的情况下需要定义接口。而一个模块为另一个模块提供服务，才需要定义接口。 5、由于采用了WCF，我们采用了SO的 设计，即在通过WCF服务的方式提供一种理想的功能共享的粒度，而Business是实现服务的方式，它和Service之间不需要太强的松耦合，不要忘了Service采用暴露在外的，并且采用Service Contract的方式进行服务消费的。 6、...

回复感言：

1.搭架子的核心是层次的划分，功能模块(包)的划分并不是关键；

2.业务逻辑层如果对存储层（DataAccess）有依赖，是无法达到隔离数据存储的目的的。不给存储层定义接口并采用依赖反转技术，是无法去掉业务逻辑层对存储层的依赖的，petshop是垃圾不做讨论；

3.一个模块的自我实现和对外接口的设计没有问题，但和业务逻辑无关，而是很薄的一个接口；

4.真正实现SOA的粗粒度服务，在自己的架子级别其实是无法实现的，更多的是靠大厂商SOA的中间件产品。用了WCF就叫SOA啦？

另：感谢Artech在WCF方面的贡献，话说我当年看WCF还费劲呢，也是看了你的帖子才豁然开朗。

我先来抛砖引玉：

传说中的弦哥:

tips：

1."解决方案文件夹"能帮助你很好的规划项目结构

2.通过对"解决方案文件夹"前面加数字1,2,3,4....，能让项目按你想要的顺序排序

3.公司名.项目名.包名.架构名的命名空间 命名约定能让你的项目结构更清晰

4.分项目的多少还是要根据项目具体情况和架构设计,分太多编译速度慢不说,其实用起来也麻烦

一晴 ：

点评:一个比较简单的博客网站，用的是MVC，命名啥的还是比较规范的。

建议：可以把Controller和Model从网站项目中提出来

xu_happy_you ：

点评：典型的Petshop控，BLL+DAL+MODEL+网站 的三层架构，通过工厂模式来调用DAL

建议：可以进一步尝试DDD，并用DI依赖注入代替工厂模式

微软根据DDD架构做的一个分层示范项目,NLayerAppV2：

下载网址：http://microsoftnlayerapp.codeplex.com/workitem/6687

微软的一个CRM项目：

下载网址：http://orchard.codeplex.com/