JavaDDD领域驱动设计(Domain Driven Design)(转)

贰.      架构详解

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(仓库储存)等各个人命关天的小圈子组件。

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

Java 1

图肆.DTO应用时序图(基于《Core J二EE Patterns》插图实行了改动)

值得一提的是,DTO对贯彻贰个单身封闭的领域模型具有积极的功力,尤其是当系统应用了1些具有活动脏数据检查
(automatic dirty
checking)机制的OEvoqueM框架时,DTO的优势就尤其明显,不然就会存在领域对象在模型层以外被意外修改并自行持久化到数据库中的风险恐怕是像
Hibernate那样的框架因未打开OpenSessionInView
(注:开启OpenSessionInView有副功能,一般认为OpenSessionInView不是壹种好的进行)而致使Lazy
Loading出现难题。

关于DTO具体的宏图用意和选取场景可参照如下财富:

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

2.《Patterns of Enterprise ApplicationArchitecture》

一.      框架结构概述

 

领域驱动设计(Domain Driven
Design)有三个合法的sample工程,名称叫DDDSample,官网:http://dddsample.sourceforge.net/,该工程给出了一种实施领域驱动设计的参考架构,本文将对此该架构进行简易介绍,并就壹些第壹难题开始展览座谈。

该架构分为了Interfaces、Applications和Domain三层以及包涵种种基础设备的Infrastructure。下图简略描述了它们之间的关联:

Java 2

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

下图是事无巨细架构:

Java 3

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

用作参考,下图显示了价值观TransactionScript风格的架构,能够看到,两者的反差并不是太大(对于Façade来说,它是壹种可选设
施,假若系统架构中省略Façade,则DTO与世界对象的交换工作可在service中展开),那也从则面表明履行领域驱动设计的第2并不在架构上,而
在于全数团队在条分缕析、设计和支出上从未有过前后地以世界模型为骨干开始展览工作,以面向对象的考虑实行规划和编制程序。

Transaction
Script风格的架构具有无可冲突的“数据”与“操作”分离的天性,其和领域驱动设计风格的架构在七个类组件上有质的分别,1个是世界对象,三个是
瑟维斯。领域驱动设计的架构宗旨目的是要创立3个富领域模型,其至高无上特征是它的小圈子对象具备充裕的作业方法用以处监护人务逻辑,而
Transaction
Script风格的天地对象则单独是数码的载体,失业方法,那种领域也被称作“贫血的圈子对象”(Anemic
Domain
Objects)。在Service方面,领域驱动设计的架构里Service是12分“薄“的壹层,其并不担负处总管情逻辑,而在
TransactionScript风格的架构里,Service是处理业务逻辑的基本点场馆,因此往往十二分沉重。

Java 4

图三:数据与操作分离的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、本田UR-VMI或Rest等在内的一种或种种通讯接口。该层主要由Façade、DTO和Assembler叁类组件构成,三类组件均是头角崭然的
J二EE情势,以下是对三类组件的有血有肉介绍:

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.

Java 5

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

Java 6

图柒.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.1.2.   Assembler

在引进DTO后,DTO与天地对象时期的相互转换工作多由Assembler承担,因而Assembler差不离连接同
DTO1起出现。也有一些体系接纳反射机制自动完成DTO与世界对象时期的相互转换,Appache的CommonsBeanUtils就提供了看似的效应。应该说那三种完成各有利弊,使用Assembler实行对象数据调换更为安全与可控,并且接受编写翻译期检查,不过代
码量显著偏多。使用反射机制自动实行象数据沟通即便代码量很少,但却是至极脆弱的,一旦目的属性名发生了变化,数据交互就会破产,并且很难追踪发现。总体
来说,Assembler更为直白和伏贴。

Java 7

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

关于Assembler具体的统一筹划用意和采纳场景可参照如下财富:

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

2.《Patterns of Enterprise ApplicationArchitecture》

二.四.    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中最广大的1类设备是目的持久化的现实性实现。

目录

一.      架构概述
2.      架构详解
        2.1.       Interfaces-接口层
                2.1.1.        DTO
                2.1.2.        Assembler
                2.1.3.        Facade
        2.2.       Application-应用层
        2.3.       Domain-领域层
        2.四.       Infrastructure-基础设施层
三.      关于框架结构的局地座谈
        三.一.       架构并无法保障领域驱动设计的落到实处与实践
        三.二.       Fa?ade是不是是必须的?

三.一.    架构并无法保障领域驱动设计的达成与执行

即使三个正好的架构对于推行世界驱动设计是大有须要的,但只依靠框架结构是无法担保领域驱动设计的落到实处与实践的。实际上,在
这一个参考架构上选用Transaction
Script的方法开始展览开法大约从不任何难题,只要开发人士将世界对象变成“贫血”的“数据载体”对待,在service里达成工作逻辑,那么该参考架构将变为纯粹的TransactionScript方式。当然反过来看,那也反映了这1框架结构的油滑。确认保障世界驱动设计的落实与实践要求方方面面团队在条分缕析、设
计和支出上未有始终地以世界模型为主导开始展览工作,以面向对象的思辨举行统一筹划和编制程序,才能确定保证落到实处世界驱动设计。

三.      关于架构的部分谈谈   

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层中任重(Ren Zhong)而道远组件便是Service,在世界驱动设计的架构里,Service的团组织粒度和接口设计
依照与价值观Transaction
Script风格的Service是一致的,不过两岸的贯彻却有着质的分别。TransactionScript风格的Service是促成业务逻辑的主要地方,由此一再十一分沉重。而在领域驱动设计的架构里,Application是万分“薄”的1层,全体的Service只承担协调并委派工作逻辑给世界
对象开始展览拍卖,其本身并确实实现工作逻辑,绝超越四分之一的作业逻辑都由世界对象承载和兑现了,那是分别系统是Transaction
Script架构照旧Domain Model框架结构的基本点标志。

不论是Transaction Script风格还Domain
Model风格,Service都会与多样组件举办交互,这么些零部件包涵:别的的Service、领域对象和Repository
或 DAO。

Java 8

图八. Service应用时序图(基于《Core J贰EE Patterns》插图举办了修改)

瑟维斯的接口是面向用例设计的,是决定工作、安全的确切地方。假诺Façade的某壹措施供给调用五个以上的Service方法,需求小心工作难题。

三.贰.    Façade是不是是必须的?

就算在架设中对Façade的概念相当鲜明,但在实践中笔者发觉Façade并不是3个简单拿捏的东西。首要难题在于其与service之间的有太多
的交汇与相似之处。我们注意到service是接口是面向1个use
case的,因而事务也是增添在service那1层上,于是对于façade而言,9九%的图景是,它只是把某部service的某些方法再封装一下而
已,如若把世界对象和DTO的互转换工作移至service中展开,那么façade将根本成为空壳,而首要的是:假使service的接口设计是面向和
user
case的,那么,毫无疑问,service接口的不胫而走传出参数也都应有是DTO,而那或多或少也在《Core
J2EE™ Patterns: Best Practices and Design Strategies,
Second艾德ition》和《帕特terns of Enterprise
ApplicationArchitecture》两书的以身作则代码中全然印证了。那么,从尤其务实角度出发,Façade并非是壹种无法不的零部件。

摘要

正文将介绍世界驱动设计(Domain Driven
Design)的合法参考架构,该架构分为了Interfaces、Applications和Domain叁层以及带有各种基础设备的
Infrastructure。本文种对架构中有的重点组件和难点进行座谈,给出1些剖析结论。

相关文章