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

摘要

本文将介绍世界驱动设计(Domain Driven
Design)的合法参考架构,该框架结构分为了Interfaces、Applications和Domain三层以及蕴涵各种基础设备的
Infrastructure。本文少禽对架构中有些首要器件和题材进行研商,给出1些剖析结论。

软件开发要干什么:

目录

一.      架构概述
二.      架构详解
        2.1.       Interfaces-接口层
                2.1.1.        DTO
                2.1.2.        Assembler
                2.1.3.        Facade
        2.2.       Application-应用层
        2.3.       Domain-领域层
        二.四.       Infrastructure-基础设施层
三.      关于架构的一对谈谈
        三.一.       架构并无法有限支撑领域驱动设计的贯彻与实施
        3.2.       Fa?ade是不是是必须的?

 

一.      架构概述

 

天地驱动设计(Domain Driven
Design)有多个官方的sample工程,名字为DDDSample,官网:http://dddsample.sourceforge.net/,该工程给出了1种实施领域驱动设计的参照架构,本文将对此该架构进行简要介绍,并就1些第二难点进行斟酌。

该架构分为了Interfaces、Applications和Domain3层以及包蕴各个基础设备的Infrastructure。下图简略描述了它们之间的关系:

lovebet 1

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

下图是事无巨细架构:

lovebet 2

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

用作参考,下图彰显了古板TransactionScript风格的架构,能够看来,两者的差别并不是太大(对于Façade来说,它是一种可选设
施,假设系统架构中省略Façade,则DTO与世界对象的沟通工作可在service中进行),那也从则面表达履行领域驱动设计的基本点并不在架构上,而
在于全部公司在解析、设计和费用上从未有过前后地以世界模型为骨干开始展览工作,以面向对象的思考进行统一筹划和编制程序。

Transaction
Script风格的架构具有显然的“数据”与“操作”分离的个性,其和天地驱动设计风格的架构在多个类组件上有质的分别,1个是世界对象,一个是
Service。领域驱动设计的架构主旨目的是要创造叁个富领域模型,其卓绝特征是它的圈子对象具备丰盛的工作方法用以处监护人务逻辑,而
Transaction
Script风格的世界对象则单纯是数据的载体,未有事情方法,那种领域也被称作“贫血的领域对象”(阿内mic
Domain
Objects)。在Service方面,领域驱动设计的框架结构里Service是尤其“薄“的壹层,其并不负担处管事人情逻辑,而在
TransactionScript风格的架构里,Service是拍卖工作逻辑的重点地方,由此往往13分厚重。

lovebet 3

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

=

  • 反映实际世界要自动化的业务流程
  • 缓解实际难点

二.      架构详解

 

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
Services、牧马人MI或Rest等在内的1种或八种通讯接口。该层主要由Façade、DTO和Assembler叁类组件构成,3类组件均是独占鳌头的
J贰EE方式,以下是对三类组件的切切实实介绍:

领域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

lovebet 4

图四.DTO应用时序图(基于《Core J2EE Patterns》插图举办了改动)

值得壹提的是,DTO对促成二个单独封闭的世界模型具有积极的效益,尤其是当系统选用了几许具有自动脏数据检查
(automatic dirty
checking)机制的O奥迪Q三M框架时,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更为直白和伏贴。

lovebet 5

图伍.Assebler应用类图(基于《Core J二EE Patterns》插图实行了改动)

有关Assembler具体的统一筹划用意和平运动用场景可参考如下能源:

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

2.《Patterns of Enterprise ApplicationArchitecture》

  • Domain特指软件关切的世界
  • 在不可能足够精通事情领域的场所下是不容许做出二个好的软件

2.1.3.   Facade

用作一种设计形式同时也是Interfaces层内的1类组件,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应该享有更粗粒度的集体依照,较为合适的粒度依照有:贰个冲天内聚的模块1个Façade,恐怕是二个“聚合”(特指领域驱动设计中的聚合)
二个Façade.

lovebet 6

图陆.Façade应用类图(基于《Core J二EE Patterns》插图举办了改动)

lovebet 7

图七.Façade应用时序图(基于《Core J二EE 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是完成工作逻辑的主要场地,因而1再十一分厚重。而在世界驱动设计的架构里,Application是不行“薄”的一层,全数的Service只负责协调并委派工作逻辑给世界
对象进行拍卖,其自个儿并确实落到实处业务逻辑,绝大多数的工作逻辑都由世界对象承载和贯彻了,那是分别系统是Transaction
Script架构依旧Domain Model架构的第2标志。

任凭是Transaction Script风格还Domain
Model风格,瑟维斯都会与多样组件举行交互,这么些组件包涵:其他的Service、领域对象和Repository
或 DAO。

lovebet 8

图八. Service应用时序图(基于《Core J二EE 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
伊芙nt(领域事件)和Repository(仓储)等二种至关心注重要的世界组件。

lovebet 9

二.四.    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中提供,防止3层尤其是Domain层掺杂进这个达成,从而“污染”领域模型。
Infrastructure中最广大的一类设备是指标持久化的现实性实现。

lovebet 10

三.      关于架构的有个别座谈   

lovebet 11

三.一.    架构并不可能保证领域驱动设计的达成与执行

即使一个恰如其分的架构对于推行世界驱动设计是大有不可或缺的,但只依靠框架结构是无法确定保障领域驱动设计的得以实现与实践的。实际上,在
这些参考架构上利用Transaction
Script的措施实行开法差不离未有别的难题,只要开发人士将世界对象变成“贫血”的“数据载体”对待,在service里完结业务逻辑,那么该参考架构将改为纯粹的TransactionScript方式。当然反过来看,那也体现了这一架构的灵活性。确定保证世界驱动设计的贯彻与实施须求全数集体在条分缕析、设
计和开发上平昔不前后地以世界模型为主题开始展览工作,以面向对象的想想实行规划和编制程序,才能保障兑现世界驱动设计。

lovebet 12

三.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
J二EE™ Patterns: Best Practices and Design Strategies,
Second艾德ition》和《Patterns of Enterprise
ApplicationArchitecture》两书的示范代码中全然印证了。那么,从进一步务实角度出发,Façade并非是一种不可能不的零部件。

天地模型驱动设计

}  分层架构

}  实体

}  值对象

}  服务

}  模块

}  聚合

}  工厂

}  资源库

 

分段架构:

lovebet 13


将世界模型相关的代码集中到2个层中,把它从用户界面、应用和基本功设备代码中分隔绝来


释放领域对象的来得自身、保存自个儿、管理选择职分等义务,让它小心于表现领域模型

}  复杂的先后切分成层

}  层中运用内聚的陈设性

}  层仅依靠于它底下的那层

 lovebet 14

实体entity: 有壹类对象拥有唯1标识符

}  能够跨越系统的生命周期甚至能跨越软件系统的一文山会海的可持续性和标识符

}  那样的指标称为实体。

值对象-value Object

}  对某些对象是哪些不感兴趣,只关怀它具有的性质

}  用来讲述领域的奇特方面、且从未标识符的一个目的,叫做值对象

}  能被略去的创造和遗弃,生命周期中不会被持久化

}  值对象足以被共享,值对象应当不可变

服务-service(比webservice更细粒度服务描述)

}  领域中的壹些动词,代表了世界中的一个根本的一颦一笑,却不属于其余对象

◦      服务实践的操作涉及一个领域概念,那个圈子概念一般不属于三个实体只怕值对象

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

◦      操作是无状态的

}  服务对象不再持有内置的境况

}  服务目标承担首要的调和作用


开发通用语言时,领域中的首要概念被引入到语言中,语言中的名词很不难被映射成对象。

言语中对应这些名词的动词变成这一个对象的行事。可是某个领域中的动作,它们是局地动词,看上去却不属于另外对象。它们代表了世界中的三个关键的一举一动,所以不能忽视它们照旧简单的把它们统一到有些实体或然值对象中。给1个目的增加那样的作为会破坏这么些指标,让它看起来拥有了相应属于它的成效。

 

模块

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


将高关联度的模子分组到一个模块以提供尽大概大的内聚(以能完好完成职分为准)

}  分层是程度划分

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

 

lovebet 15

lovebet 16

lovebet 17

lovebet 18

 

参考框架结构概述

}  领域驱动设计(DomainDriven
Design)有三个法定的sample工程,名字为DDDSample

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

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

架构概述

 lovebet 19

详见框架结构

 lovebet 20

架构详解:Interfaces-接口层

lovebet 21

}  该层包涵与别的系统进行相互的接口与通信装备,在大部施用里

}  可能提供包罗WebServices、途观MI或Rest等在内的一种或多样通信接口


该层主要由Facade、DTO和Assembler3类组件构成,三类组件均是独立的J二EE形式

DTO

lovebet 22

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


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

DTO 作用

}  收缩网络流量

}  简化远程对象和长距离接口

}  传输越来越多的数据减少长距离调用次数

}  制止将世界情形跨层次传递

}  由于共同和版本控制扩大了复杂

DTO 应用时序图

lovebet 23

Assembler

lovebet 24

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

}  由此Assembler大概连接同DTO一起出现。

Assembler 落成方案

lovebet 25

Façade

lovebet 26

}  实践Facade的进度中最难把握的题材就是Facade的粒度难题。


古板的Service均以实体为单位开始展览集体,而Facade应该有着更粗粒度的团体依据,较为适宜的粒度依据有:

}  贰个可观内聚的模块三个Facade

}  或许是一个“聚合”(特指领域驱动设计)三个Facade.

Facade 达成方案

lovebet 27

Facade 应用时序图

lovebet 28

Service

lovebet 29

}  Service会与几种组件进行互动

}  那个零件包涵:

◦      其他的Service

◦      领域对象

◦      Repository

◦      DAO

Service 应用时序图

lovebet 30

Domain-领域层

lovebet 31


Domain层是整整种类的中坚层,该层维护3个施用面向对象技术实现的小圈子模型,差不离任何的工作逻辑会在该层达成

}  Domain层包含:

◦      Entity(实体)

◦      ValueObject(值对象)

◦      Domain 伊夫nt(领域事件)

◦      Repository(仓储)等

Infrastructure-基础设施层

lovebet 32

}  基础设备层nfrastructure为Interfaces、Application和Domain3层提供帮忙


全体与现实平台、框架相关的贯彻会在Infrastructure中提供,制止3层尤其是Domain层掺杂进那个达成,从而“污染”领域模型

}  Infrastructure中最普遍的1类设施是目的持久化的求实达成

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

lovebet 33

DDD && SOA

}  DDD 领域模型驱动设计

}  SOA  面向服务的架构