实体框架之领域驱动实践（二）：分层架构

在引入实例以前,我们有必要回顾,并进一步了解分层架构.“层”是一种体系结构模式^[POSA1],也是被广大软件从业人员用得最为广泛而且最为灵活的模式之一.记得在CSDN上,时常有朋友问到:“分层是什么?为什么要分层?三层架构是不是就是表现层、业务逻辑层和数据访问层?”

到这里,你可能会觉得这些朋友的问题很简单,分层嘛,不就是将具有不同职责的组件分离开来,组成一套层内部高聚合,层与层之间低耦合的软件系统吗?不错!这是分层的目标.但是,我们应该如何分层呢?

领域驱动设计的讨论同样也是建立在层模式的基础上的,但与传统的分层架构相比,它更注重领域架构和技术架构的分离.

传统的三层架构

如上文那位朋友提的问题那样,最简单的分层方式自然就是“表现层、业务逻辑层和数据访问层”,我们可以用下图来表示这个思想:

注意图中打虚线的“基础结构层”,从实践的表现上来看,这部分内容可能就是一些帮助类,比如SQLHelper之类的,也可能是一些工具类,比如TextUtility之类.这些东西可以被其它各层所访问.而基于分层的概念,表现层只能跟业务逻辑层打交道,而业务逻辑层在数据持久化方面的操作,则依赖于数据访问层.表现层对数据访问层的内容一无所知.

从领域驱动的角度看,这种分层的方式有一定的弊端.首先,为各个层面提供服务的“基础结构层”的职责比较紊乱,它可以是纯粹的技术框架,也可以包含或处理一定的业务逻辑,这样一来,业务逻辑层与“基础结构层”之间就会存在依赖关系;其次,这种结构过分地突出了“数据访问”的地位,把“数据访问” 与“业务逻辑”放在了等同的地位,这也难怪很多软件人员一上来就问:“我的数据表该如何设计?”

领域驱动设计的分层

领域驱动设计将软件系统分为四层:基础结构层、领域层、应用层和表现层.与上述的三层相比,数据访问层已经不在了,它被移到基础结构层了.

基础结构层:该层专为其它各层提供技术框架支持.注意,这部分内容不会涉及任何业务知识.众所周知的数据访问的内容,也被放在了该层当中,因为数据的读写是业务无关的

领域层:包含了业务所涉及的领域对象(实体、值对象)、领域服务以及它们之间的关系.这部分内容的具体表现形式就是领域模型(Domain Model).领域驱动设计提倡富领域模型,即尽量将业务逻辑归属到领域对象上,实在无法归属的部分则以领域服务的形式进行定义.有关领域对象和领域服务的内容,我会在接下来的案例中进行阐述

应用层:该层不包含任何领域逻辑,但它会对任务进行协调,并可以维护应用程序的状态,因此,它更注重流程性的东西.在某些领域驱动设计的实践中,也会将其称为“工作流层”.应用层是领域驱动中最有争议的一个层次,也会有很多人对其职责感到模糊不清.比如,有些国外的开发人员会觉得,既然不包含领域逻辑,那又如何协调工作任务呢?我会在《应用层与实体事件》章节对这些问题进行探讨

表现层:这个好理解,跟三层里的表现层意思差不多,但请注意,“Web服务”虽然是服务,但它是表现层的东西

从上图还可以看到,表现层与应用层之间是通过数据传输对象(DTO)进行交互的,数据传输对象是没有行为的POCO对象,它的目的只是为了对领域对象进行数据封装,实现层与层之间的数据传递.为何不能直接将领域对象用于数据传递?因为领域对象更注重领域,而DTO更注重数据.不仅如此,由于“富领域模型”的特点,这样做会直接将领域对象的行为暴露给表现层.

从下一个章节开始,我将以最简单的销售系统为例,介绍实体框架(Entity Framework,简称EF)下领域驱动设计的应用.