转载

领域驱动设计架构

编辑推荐:

本文来自于csdn,本文主要介绍领域驱动设计风格的架构以及各个层的详解以下是对三类组件的具体介绍。

一、领域驱动设计架构

领域驱动设计架构分成接口层(interfaces)、应用层(Applications)、领域层(Domain)以及基础设施层(Infrastructure)。下图描述这四者的简略图：

领域驱动设计架构

图一：领域驱动设计风格的架构草图

四者的详细架构图：

领域驱动设计架构

图二：领域驱动设计参考架构

传统的三层构图：

领域驱动设计架构

图三：传统三层架构图

说明：

作为参照，下图展示了传统TransactionScript风格的架构，可以看出，两者的差异并不是太大（对于Facade来说，它是一种可选设施，如果系统架构中省略Facade，则DTO与领域对象的互换工作可在service中进行），这也从侧面说明推行领域驱动设计的关键并不在架构上，而在于整个团队在分析、设计和开发上没有自始至终地以领域模型为核心开展工作，以面向对象的思想进行设计和编程。

Transaction Script风格的架构具有明显的“数据”与“操作”分离的特征，其和领域驱动设计风格的架构在两个类组件上有质的区别，一个是领域对象，一个是 Service。领域驱动设计的架构核心目标是要创建一个富领域模型，其典型特征是它的领域对象具有丰富的业务方法用以处理业务逻辑，而 Transaction Script风格的领域对象则仅仅是数据的载体，没有业务方法，这种领域也被称作“贫血的领域对象”(Anemic Domain Objects)。在Service方面，领域驱动设计的架构里Service是非常“薄“的一层，其并不负责处理业务逻辑，而在 Transaction Script风格的架构里，Service是处理业务逻辑的主要场所，因而往往非常厚重。

二、各层详解

1.Interfaces-接口层

领域驱动设计对Interfaces的定位是:

该层包含与其他系统进行交互的接口与通信设施，在多数应用里，该层可能提供包括Web Services、RMI或Rest等在内的一种或多种通信接口。该层主要由Facade、DTO和Assembler三类组件构成，三类组件均是典型的 J2EE模式。

以下是对三类组件的具体介绍：

1.1.DTO

DTO- DataTransfer Object（数据传输对象），也常被称作VO-Value Object(值对象)。基于面向对象技术设计的领域对象（即通常所说的“实体”）都是细粒度的，将细粒度的领域对象直接传递到远程调用端需要进行多次网络通信，DTO在设计之初的主要考量是以粗粒度的数据结构减少网络通信并简化调用接口。以下罗列了DTO的多项作用：

减少网络流量

简化远程对象和远程接口

在更少的远程调用中传输更多的数据

减少代码重复

说明陈旧的传输对象

由于同步和版本控制而增加了复杂性

1.2.Assembler

在引入DTO后，DTO与领域对象之间的相互转换工作多由Assembler承担，因此Assembler几乎总是同DTO一起出现。也有一些系统使用反射机制自动实现DTO与领域对象之间的相互转换。

1.3.Facade

作为一种设计模式同时也是Interfaces层内的一类组件，Facade的用意在于为远程客户端提供粗粒度的调用接口。Facade本身不处理任何的业务逻辑，它的主要工作就是将一个用户请求委派给一个或多个Service进行处理，同时借助Assembler将Service传入或传出的领域对象转化为DTO进行传输。以下罗列了Facade的多项作用：

介绍一种为远程客户端提供服务的层

公开一个统一的粗粒度接口

减少层之间的耦合

促进分层，增加灵活性和可维护性

降低复杂性

改进性能，减少细粒度的远程方法

集中安全管理

集中使用事务控制

向客户机公开更少的远程接口

2.Application-应用层

领域驱动设计对Application的定位是:

Application层中主要组件就是Service,在领域驱动设计的架构里，Service的组织粒度和接口设计依据与传统Transaction Script风格的Service是一致的，但是两者的实现却有着质的区别。Transaction Script风格的Service是实现业务逻辑的主要场所，因此往往非常厚重。而在领域驱动设计的架构里，Application是非常“薄”的一层，所有的Service只负责协调并委派业务逻辑给领域对象进行处理，其本身并真正实现业务逻辑，绝大部分的业务逻辑都由领域对象承载和实现了，这是区别系统是Transaction Script架构还是Domain Model架构的重要标志。不管是Transaction Script风格还是Domain Model风格，Service都会与多种组件进行交互，这些组件包括：其他的Service、领域对象和Repository 或 DAO。

3. Domain-领域层

领域驱动设计对Domain的定位是:

Domain层是整个系统的核心层，该层维护一个使用面向对象技术实现的领域模型，几乎全部的业务逻辑会在该层实现。Domain层包含 Entity（实体）、ValueObject(值对象)、Domain Event（领域事件）和Repository（仓储）等多种重要的领域组件。仓储是在领域层定义，在基础设施层实现

4. Infrastructure-基础设施层

领域驱动设计对Infrastructure的定位是:

作为基础设施层，Infrastructure为Interfaces、Application和Domain三层提供支撑。所有与具体平台、框架相关的实现会在Infrastructure中提供，避免三层特别是Domain层掺杂进这些实现，从而“污染”领域模型。 Infrastructure中最常见的一类设施是对象持久化的具体实现。

5.具体流程图

领域驱动设计架构