领域模型驱动设计,DDD领域驱动设计

摘要

正文将介绍世界驱动设计(Domain Driven
Design)的法定参谋架构,该架构分为了Interfaces、Applications和Domain三层以及含有种种基础设备的
Infrastructure。本文少禽对架构中一些第一组件和题材张开钻探,给出一些深入分析结论。

软件开拓要怎么:

目录

1.      框架结构概述
2.      架构详解
        2.1.       Interfaces-接口层
                2.1.1.        DTO
                2.1.2.        Assembler
                2.1.3.        Facade
        2.2.       Application-应用层
        2.3.       Domain-领域层
        2.4.       Infrastructure-基础设施层
3.      关于架构的有的商酌
        3.1.       架构并不可能确定保证领域驱动设计的贯彻与实施
        3.2.       Fa?ade是或不是是必得的?

 

1.      架构概述

 

领域驱动设计(Domain Driven
Design)有四个法定的sample工程,名称为DDDSample,官方网站:http://dddsample.sourceforge.net/,该工程给出了一种实行领域驱动设计的参阅架构,本文将对此该架构进行简介,并就有些生死攸关难点张开座谈。

该架构分为了Interfaces、Applications和Domain三层以及含有各个基础设备的Infrastructure。下图简略描述了它们之间的涉嫌:

图片 1

图1:领域驱动设计风格的架构草图(来自于DDD萨姆ple官方网站)

下图是事无巨细框架结构:

图片 2

图2:领域驱动设计参照架构

作为参照,下图展现了观念TransactionScript风格的架构,能够看到,两个的距离并非太大(对于Façade来讲,它是一种可选设
施,倘若系统架构中省略Façade,则DTO与天地对象的交换职业可在service中开展),那也从则面表明执行领域驱动设计的机要并不在架构上,而
在于全体集体在剖析、设计和付出上从不始终地以世界模型为主旨开展职业,以面向对象的思考举行设计和编制程序。

Transaction
Script风格的架构具有无可争辨的“数据”与“操作”分离的特色,其和领域驱动设计风格的框架结构在八个类组件上有质的分别,贰个是世界对象,一个是
Service。领域驱动设计的架构宗旨目的是要开创贰个富领域模型,其高高在上特征是它的小圈子对象具有丰裕的作业方法用以处管事人务逻辑,而
Transaction
Script风格的领域对象则单独是数据的载体,没有事情方法,这种领域也被称作“贫血的园地对象”(Anemic
Domain
Objects)。在Service方面,领域驱动设计的架构里Service是特别“薄“的一层,其并不担任处管事人情逻辑,而在
TransactionScript风格的架构里,Service是拍卖职业逻辑的要紧场合,因此往往极其厚重。

图片 3

图3:数据与操作分离的Transaction Script风格的架构

=

  • 反映实际世界要自动化的业务流程
  • 赶尽杀绝现实主题材料

2.      架构详解

 

2.1.    Interfaces-接口层

 

世界驱动设计对Interfaces的一定是:

Thislayer holds everything that interacts with other systems, such as
web services,RMI interfaces or web applications, and batch processing
frontends. It handlesinterpretation, validation and translation of
incoming data. It also handlesserialization of outgoing data, such as
HTML or XML across HTTP to web browsersor web service clients, or DTO
classes and distributed facade interfaces forremote Java clients.

该层满含与别的系统开展互动的接口与通信设备,在好多使用里,该层恐怕提供包罗Web
瑟维斯s、RMI或Rest等在内的一种或两种通信接口。该层主要由Façade、DTO和Assembler三类组件构成,三类组件均是优异的
J2EE形式,以下是对三类组件的具体介绍:

领域Domain

2.1.1.   DTO

DTO- DataTransfer Object(数据传输对象),也常被称作VO-Value
Object(值对象)。基于面向对象技术设计的天地对象(即平日所说的“实体”)都以细粒度的,将细粒度的园地对象直接传送到长途调用端须要实行数次互连网通讯,DTO在设计之初的机要考虑衡量是以粗粒度的数据结构收缩互联网通讯并简化调用接口。以下罗列了DTO的多项成效:

  •         Reduces network traffic

  •         Simplifies remote object and remote interface

  •         Transfers more data in fewer remote calls

  •         Reduces code duplication

  •         Introduces stale transfer objects

  •         Increases complexity due to synchronization and version
    control

图片 4

图4.DTO应用时序图(基于《Core J2EE Patterns》插图进行了退换)

值得一提的是,DTO对落到实处贰个单身密封的天地模型具有积极的效应,极其是当系统利用了一些具备活动脏数据检查
(automatic dirty
checking)机制的ORM框架时,DTO的优势就更为断定,否则就能存在领域对象在模型层以外被意外修改并自行持久化到数据库中的风险也许是像
Hibernate那样的框架因未张开OpenSessionInView
(注:开启OpenSessionInView有副功用,一般以为OpenSessionInView不是一种好的进行)而致使Lazy
Loading出现难点。

至于DTO具体的安排用意和应用场景可参看如下能源:

1.《Core J2EE™ Patterns: Best Practices and Design Strategies,
SecondEdition》

2.《Patterns of Enterprise ApplicationArchitecture》

 

2.1.2.   Assembler

在引入DTO后,DTO与世界对象之间的互相转换事业多由Assembler承担,由此Assembler大约连接同
DTO一同现身。也是有部分体系采纳反射机制自动完成DTO与天地对象时期的并行调换,Appache的CommonsBeanUtils就提供了看似的功力。应该说那二种完毕各有利弊,使用Assembler实行对象数据沟通更为安全与可控,並且接受编写翻译期检查,可是代
码量明显偏多。使用反射机制自动举办象数据调换即使代码量比很少,但却是极其柔弱的,一旦目的属性名产生了转移,数据交互就能够停业,何况很难跟踪开掘。总体
来讲,Assembler更为直白和稳妥。

图片 5

图5.Assebler应用类图(基于《Core J2EE Patterns》插图实行了改换)

有关Assembler具体的统一策动用意和应用场景可参照他事他说加以考察如下财富:

1.《Core J2EE™ Patterns: Best Practices and Design Strategies,
SecondEdition》

2.《Patterns of Enterprise ApplicationArchitecture》

  • Domain特指软件关怀的园地
  • 在无法充裕通晓事情领域的情事下是不容许做出一个好的软件

2.1.3.   Facade

用作一种设计形式同不常间也是Interfaces层内的一类组件,Façade的企图在于为远程客商端提供粗粒度的调用接口。Façade本人不处理任何的事体逻辑,它的基本点办事正是将五个顾客须求委派给一个或三个Service进行拍卖,同期借助Assembler将Service传入或传播的小圈子
对象转化为DTO举办传输。以下罗列了Façade的多项功效:

  • Introduces a layer that provides services to remote clients

  • Exposes a uniform coarse-grained interface

  • Reduces coupling between the tiers

  • Promotes layering, increases flexibility and maintainability

  • Reduces complexity

  • Improves performance, reduces fine-grained remote methods

  • Centralizes security management

  • Centralizes transaction control

  • Exposes fewer remote interfaces to clients

施行Façade的进度中最难把握的标题就是Façade的粒度难题。古板的Service均以实体为单位举行集体,而
Façade应该具有更加粗粒度的集团依据,较为适宜的粒度依赖有:八个中度内聚的模块三个Façade,或许是三个“聚合”(特指领域驱动设计中的聚合)
多个Façade.

图片 6

图6.Façade应用类图(基于《Core J2EE Patterns》插图进行了修改)

图片 7

图7.Façade应用时序图(基于《Core J2EE Patterns》插图进行了修改)

有关Assembler具体的陈设性用意和行使场景可参照他事他说加以考察如下财富:

1.《Core J2EE™ Patterns: Best Practices and Design Strategies,
SecondEdition》

2.《Patterns of Enterprise ApplicationArchitecture》

3.《Design Patterns: Elementsof Reusable Object-Oriented Software》

 

2.2.    Application-应用层

 

天地驱动设计对Application的稳定是:

Theapplication layer is responsible for driving the workflow of the
application,matching the use cases at hand. These operations are
interface-independent andcan be both synchronous or message-driven. This
layer is well suited forspanning transactions, high-level logging and
security. The application layeris thin in terms of domain logic – it
merely coordinates the domain layerobjects to perform the actual work.

Application层中首要组件就是Service,在天地驱动设计的架构里,Service的公司粒度和接口设计
依据与历史观Transaction
Script风格的Service是一样的,不过双方的实现却有着质的区分。TransactionScript风格的Service是实现业务逻辑的重要场合,因而反复特别沉重。而在圈子驱动设计的架构里,Application是那一个“薄”的一层,全部的Service只负担和睦并委派专门的工作逻辑给世界
对象开展管理,其本人并确实贯彻专门的职业逻辑,绝超过十分之五的专门的学问逻辑都由世界对象承载和兑现了,那是分别系统是Transaction
Script架构照旧Domain Model架构的主要标记。

不论是是Transaction Script风格还Domain
Model风格,Service都会与三种零件实行互相,那几个零件包含:别的的Service、领域对象和Repository
或 DAO。

图片 8

图8. Service应用时序图(基于《Core J2EE Patterns》插图进行了改造)

Service的接口是面向用例设计的,是调节作业、安全的妥当地方。假诺Façade的某一主意需求调用七个以上的Service方法,供给留神专业难点。

 领域建立模型

2.3.    Domain-领域层

 

世界驱动设计对Domain的定位是:

Thedomain layer is the heart of the software, and this is where the
interestingstuff happens. There is one package per aggregate, and to
each aggregatebelongs entities, value objects, domain events, a
repository interface andsometimes factories.

Thecore of the business logic belongs in here. The structure and naming
ofaggregates, classes and methods in the domain layer should follow
theubiquitous language, and you should be able to explain to a domain
expert howthis part of the software works by drawing a few simple
diagrams and using theactual class and method names of the source code.

Domain层是任何连串的中坚层,该层维护三个运用面向对象本领实现的园地模型,差非常的少整个的政工逻辑会在该层完结。
Domain层包括Entity(实体)、ValueObject(值对象)、Domain
Event(领域事件)和Repository(仓库储存)等两种重要的领域组件。

图片 9

2.4.    Infrastructure-基础设施层

领域驱动设计对Infrastructure的一贯是:

Inaddition to the three vertical layers, there is also the
infrastructure. As thethe picture shows, it supports all of the three
layers in different ways,facilitating communication between the layers.
In simple terms, theinfrastructure consists of everything that exists
independently of ourapplication: external libraries, database engine,
application server, messagingbackend and so on.

Also,we consider code and configuration files that glues the other
layers to theinfrastructure as part of the infrastructure layer. Looking
for example at thepersistence aspect, the database schema definition,
Hibernate configuration andmapping files and implementations of the
repository interfaces are part of theinfrastructure layer.

Whileit can be tricky to give a solid definition of what kind of code
belongs to theinfrastructure layer for any given situation, it should be
possible tocompletely stub out the infrastructure in pure Java
unit/scenario tests andstill be able to use the domain layer and
possibly the application layer towork out the core business problems.

用作基础设备层,Infrastructure为Interfaces、Application和Domain三层提供
支撑。全体与现实平台、框架相关的兑现会在Infrastructure中提供,防止三层特别是Domain层掺杂进这么些完成,进而“污染”领域模型。
Infrastructure中最常见的一类设备是目的漫长化的切切实实贯彻。

图片 10

3.      关于架构的片段批评   

图片 11

3.1.    架构并不能够担保领域驱动设计的落到实处与实行

就算二个老少咸宜的架构对于进行世界驱动设计是大有至关重要的,但只凭借框架结构是不可能确定保证领域驱动设计的落到实处与施行的。实际上,在
那几个参谋架构上选拔Transaction
Script的不二等秘书技实行开法大概从不其余难题,只要开垦职员将世界对象产生“贫血”的“数据载体”对待,在service里实现业务逻辑,那么该参谋架构将变为纯粹的TransactionScript方式。当然反过来看,那也呈现了这一架构的灵活性。确定保证世界驱动设计的贯彻与施行必要整个团队在条分缕析、设
计和支出上从没有过前后地以世界模型为骨干开展专业,以面向对象的思念举办规划和编制程序,工夫确认保证兑现世界驱动设计。

图片 12

3.2.    Façade是不是是必得的?

即便在架设中对Façade的定义极度清楚,但在实践中笔者发觉Façade并不是一个便于拿捏的事物。主要难题在于其与service之间的有太多
的交汇与相似之处。大家注意到service是接口是面向四个use
case的,因而事务也是扩张在service这一层上,于是对于façade来说,99%的情况是,它只是把某部service的有个别方法再装进一下而
已,如果把世界对象和DTO的互转变专门的学问移至service中开展,那么façade将根本产生空壳,而重大的是:假如service的接口设计是面向和
user
case的,那么,不容争辩,service接口的传入传出参数也都应当是DTO,而这点也在《Core
J2EE™ Patterns: Best Practices and Design Strategies,
SecondEdition》和《Patterns of Enterprise
ApplicationArchitecture》两书的演示代码中完全印证了。那么,从越发务实角度出发,Façade并不是是一种不能够不的零件。

领域模型驱动设计

}  分层架构

}  实体

}  值对象

}  服务

}  模块

}  聚合

}  工厂

}  资源库

 

分段框架结构:

图片 13


将世界模型相关的代码聚集到贰个层中,把它从客商分界面、应用和根基设备代码中分隔绝来


释放领域对象的显得本身、保存本人、管理选拔职务等职分,让它小心于表现领域模型

}  复杂的主次切分成层

}  层中选取内聚的图谋

}  层仅凭仗于它底下的那层

 图片 14

实体entity: 有一类对象具有独一标记符

}  能够当先系统的生命周期乃至能赶过软件系统的一密密麻麻的接二连三性和标志符

}  那样的目的称为实体。

值对象-value Object

}  对有个别对象是怎么不感兴趣,只关切它兼具的本性

}  用来描述领域的奇特方面、且尚未标记符的三个指标,叫做值对象

}  能被轻易的创造和遗弃,生命周期中不会被悠久化

}  值对象足以被分享,值对象应该不可变

劳动-service(比webservice越来越细粒度服务描述)

}  领域中的一些动词,代表了世界中的一个至关心重视要的一坐一起,却不属于其他对象

◦      服务实行的操作涉及贰个领域概念,这么些圈子概念一般不属于叁个实体或许值对象

◦      被实行的操作涉及到世界中的其余的靶子

◦      操作是无状态的

}  服务对象不再持有内置的图景

}  服务目标承担主要的调养功用


开采通用语言时,领域中的重要概念被引进到语言中,语言中的名词很轻易被映射成对象。

语言中对应那么些名词的动词产生那几个对象的表现。可是多少领域中的动作,它们是一对动词,看上去却不属于其余对象。它们代表了世界中的二个主要的一举一动,所以不可以小看它们恐怕轻松的把它们统一到有个别实体只怕值对象中。给贰个对象扩充那样的行事会毁掉那几个指标,让它看上去具有了应有属于它的效果与利益。

 

模块

}  将相关领域模型提炼分类,分而治之


将高关联度的模子分组到三个模块以提供尽恐怕大的内聚(以能完全完毕职分为准)

}  分层是水平划分

}  模块是笔直细分(Domain内部)

 

图片 15

图片 16

图片 17

图片 18

 

参照架构概述

}  领域驱动设计(DomainDriven
Design)有三个官方的sample工程,名字为DDD萨姆ple

}  官网:http://dddsample.sourceforge.net/

}  该工程给出了一种实践领域驱动设计的参阅架构

架构概述

 图片 19

详尽架构

 图片 20

框架结构详解:Interfaces-接口层

图片 21

}  该层包含与另外系统开展互动的接口与通讯设备,在多数行使里

}  恐怕提供富含Web瑟维斯s、RMI或Rest等在内的一种或两种通讯接口


该层主要由Facade、DTO和Assembler三类组件构成,三类组件均是标准的J2EE方式

DTO

图片 22

}  DTO- DataTransfer
Object(数据传输对象),也常被称作VO-ValueObject(值对象)


DTO设计之初是为了将细粒度的圈子对象包装为粗粒度的数据结构,收缩互连网通讯并简化调用接口

DTO 作用

}  收缩网络流量

}  简化远程对象和远程接口

}  传输更加多的多寡减弱长距离调用次数

}  幸免将世界景况跨档次传递

}  由于联合和版本调控增添了复杂

DTO 应用时序图

图片 23

Assembler

图片 24

}  DTO与世界对象期间的交互转变工作多由Assembler承担

}  由此Assembler大约总是同DTO一齐出现。

Assembler 达成方案

图片 25

Façade

图片 26

}  执行Facade的长河中最难把握的主题素材就是Facade的粒度难点。


古板的Service均以实体为单位开展团队,而Facade应该具有更粗粒度的组织依据,较为适宜的粒度依赖有:

}  多个可观内聚的模块一个Facade

}  或然是叁个“聚合”(特指领域驱动设计)二个Facade.

Facade 完成方案

图片 27

Facade 应用时序图

图片 28

Service

图片 29

}  Service会与种种零件进行相互

}  那个零部件包括:

◦      其他的Service

◦      领域对象

◦      Repository

◦      DAO

Service 应用时序图

图片 30

Domain-领域层

图片 31


Domain层是百分之百种类的主旨层,该层维护三个施用面向对象技艺达成的世界模型,大概任何的事情逻辑会在该层实现

}  Domain层包含:

◦      Entity(实体)

◦      ValueObject(值对象)

◦      Domain Event(领域事件)

◦      Repository(仓储)等

Infrastructure-基础设施层

图片 32

}  基础设备层nfrastructure为Interfaces、Application和Domain三层提供支撑


全部与具体平台、框架相关的落到实处会在Infrastructure中提供,幸免三层特别是Domain层掺杂进这个达成,进而“污染”领域模型

}  Infrastructure中最广泛的一类设备是目的悠久化的具体落到实处

“守旧”架构-贫血领域模型

图片 33

DDD && SOA

}  DDD 领域模型驱动设计

}  SOA  面向服务的架构

相关文章