传统三层架构与DDD分层架构

转载地址：https://www.cnblogs.com/sandyliu1999/p/4969445.html

传统三层架构，即用户界面层UI、业务逻辑层BAL、数据访问层DAL。一般同时还有建立一个Model实体类的工程项目。DDD分层架构，即表现层UI、应用层Application、领域驱动层Doman、基础设施层Infrastructure。

 

传统三层架构，我一直使用、结构单一、逻辑也清晰，三层各处理各自的事务，上层向下层引用接口与方法，下层向上层提供接口服务，各层之间调度方法时可能通过Model传值，也可以返回值Model。但以往，我处理的业务逻辑层中，基本上都是将DAL层的接口值返回给业务逻辑层，然后BLL层再将结果返回给UI层，BLL层只做了上传下达的作用，其它的作用发挥得较少。以往三层架构中的重点是BLL层。当我需要新增业务功能时，或者需要CRUD操作，需要将UI层、BLL层、DAL层都需要增加类文件以达到处理CRUD操作的功能。当然，传统三层架构中，也会引入一个新的Common工程或Utility工程，为BLL、DAL、UI提供共用或通用方法或行为的支持。若是有需要对第三方软件或系统提供数据接口，这时，可以将接口作为IIS站点或WebService 或WebAPI提供，此时这个接口可以放在UI供第三方调用。

DDD分层架构，是从传三层架构中演变过来的。它将传统的三层架构做了一定的变更，将四个层中的内容做了重新归内，并对分层结构的业务重点作了分配。UI层还是UI层、应用层用于调度第三方的应用接口、以及提供口服务给第三方，同时将在应用层增加Dto工程项目用于操作应用层与UI层的数据传递即值对象传递以及Dto与Model实体类之间的映射，将传统的BLL层、Model层归纳到领域驱动层Domain中，同时将仓储的接口层放在Domain层中，将传统的DAL层实现以及通用的Common层或Utility层归纳到基础设施层Infrastructure中。

 

从传统三层架构（包括Common公共层、Model实体层）演变到DDD领域驱动模型设计的分层架构，从项目归纳上比较，可能多了DAL接口层即仓储接口层，其它的工程项目只是做了位置上的迁移。同时传统BLL层的命名变理为Service，同时在应用层增加了Dto工程项目。

从这种演变上可以看出，进一步将层与层之间的耦合减低、将Dto（数据传输层-值对象）引入，给表现层提供了更多的数据展示的灵活性。更多演变的体验，后续文章再叙述。

解决方案结构命名可参考http://www.cnblogs.com/lori/p/3345590.html

 

http://www.cnblogs.com/daxnet/archive/2010/07/07/1772584.html

http://www.cnblogs.com/daxnet/archive/2011/05/10/2042095.html