DDD-Learning

     领域驱动　　

      领域驱动设计是一种思想，它不是模式也不是方法论。很难用一句话来概括什么是领域驱动设计，就好比很难用一句话来概括什么是***思想一样。
领域驱动设计要求立足领域，于是，领域专家（Domain Experts）和软件人员都需要很好地理解领域的方方面面，因此，沟通就成了关键因素。领域专家不懂技术，软件人员对领域也一知半解。为了减小沟通上的差距，领域驱动设计提出了通用语言的概念，所谓通用语言，就是在特定领域的界定上下文中，无二义的概念描述形式。我们平时经常接触类似通用语言的东西，代表就是LINQ以及Microsoft Dynamics AX X++语法中的集成查询功能。
通用语言贯穿了领域驱动设计的方方面面，是领域驱动设计的核心。我们在设计中所关注的实体、值对象、服务、仓储等概念，都是领域驱动设计实践中总结出来的实践方式。不仅如此，为了实现领域驱动，我们可能会根据需求，在实现上适当地选取一些设计模式、体系结构模式以及惯用法（《面向模式的软件体系结构 卷1：模式系统》将模式分为三类：设计模式、体系结构模式和惯用法）。这也是为什么我们在谈及领域驱动的架构设计过程中，经常会引用模式的原因。

   分层架构

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

 

    传统的三层架构

    最简单的分层方式自然就是“表现层、业务逻辑层和数据访问层”。

                                                                                  

 

从领域驱动的角度看，这种分层的方式有一定的弊端。首先，为各个层面提供服务的“基础结构层”的职责比较紊乱，它可以是纯粹的技术框架，也可以包含或处理一定的业务逻辑，这样一来，业务逻辑层与“基础结构层”之间就会存在依赖关系；其次，这种结构过分地突出了“数据访问”的地位，把“数据访问”与 “业务逻辑”放在了等同的地位。

      领域驱动设计的分层

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

• 基础结构层：该层专为其它各层提供技术框架支持。注意，这部分内容不会涉及任何业务知识。众所周知的数据访问的内容，也被放在了该层当中，因为数据的读写是业务无关的
• 领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。
• 应用层：该层不包含任何领域逻辑，但它会对任务进行协调，并可以维护应用程序的状态，因此，它更注重流程性的东西。在某些领域驱动设计的实践中，也会将其称为“工作流层”。
• 表现层：这个好理解，跟三层里的表现层意思差不多，但请注意，“Web服务”虽然是服务，但它是表现层的东西

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