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

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

模型是抽象的

现实是形象的

技巧是重要的

思想是永恒的

从传统三层架构与DDD分层架构的编程演变实际上是思想的演变。 

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

 

传统三层架构，我一直使用、结构单1、逻辑也清晰，三层各处理各自的事务，上层向下层引用接口与方法，下层向上层提供接口服务，各层之间调度方法时可能经过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