目录

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是不是是必须的?

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

图片 1

图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.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的集体粒度和接口设计
根据与历史观Transaction
Script风格的Service是一律的,不过双方的兑现却有着质的不一致。TransactionScript风格的瑟维斯是促成工作逻辑的主要场馆,由此往往更加厚重。而在领域驱动设计的架构里,Application是那个“薄”的一层,所有的Service只承担协调并委派工作逻辑给世界
对象开展处理,其本人并确实已毕工作逻辑,绝大多数的政工逻辑都由世界对象承载和兑现了,这是分别系统是Transaction
Script架构仍旧Domain Model架构的严重性标志。

不管是Transaction Script风格还Domain
Model风格,Service都会与四种组件举行交互,那几个组件包含:其余的Service、领域对象和Repository
或 DAO。

图片 2

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

Service的接口是面向用例设计的,是控制工作、安全的适合场合。即使Façade的某一措施需求调用四个以上的Service方法,需求小心工作难点。

1.      架构概述

 

领域驱动设计(Domain Driven
Design)有一个法定的sample工程,名为DDD萨姆ple,官网:http://dddsample.sourceforge.net/,该工程给出了一种实施领域驱动设计的参阅架构,本文将对此该架构举办简易介绍,并就有的要害难点展开座谈。

该架构分为了Interfaces、Applications和Domain三层以及富含各样基础设备的Infrastructure。下图简略描述了它们中间的关联:

图片 3

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

下图是事无巨细架构:

图片 4

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

作为参照,下图浮现了价值观TransactionScript风格的架构,可以看看,两者的歧异并不是太大(对于Façade来说,它是一种可选设
施,假如系统架构中省略Façade,则DTO与世界对象的互换工作可在service中举行),那也从则面表达履行领域驱动设计的主要并不在架构上,而
在于所有集团在解析、设计和开发上平素不前后地以世界模型为着力开展工作,以面向对象的思维举行设计和编程。

Transaction
Script风格的架构具有强烈的“数据”与“操作”分离的表征,其和世界驱动设计风格的架构在八个类组件上有质的界别,一个是小圈子对象,一个是
Service。领域驱动设计的架构要旨目的是要开创一个富领域模型,其至高无上特征是它的小圈子对象具备丰裕的事情方法用以处理工作逻辑,而
Transaction
Script风格的天地对象则单独是数量的载体,无业方法,那种领域也被称作“贫血的圈子对象”(Anemic
Domain
Objects)。在Service方面,领域驱动设计的架构里Service是不行“薄“的一层,其并不负责处管事人务逻辑,而在
TransactionScript风格的架构里,Service是处监护人情逻辑的要紧场所,由此往往分外沉重。

图片 5

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

=

3.      关于架构的片段议论   

3.1.    架构并不可能保险领域驱动设计的落到实处与实践

即使如此一个适宜的架构对于进行世界驱动设计是大有必不可少的,但只依靠架构是不可以有限支撑领域驱动设计的贯彻与实施的。实际上,在
这几个参考架构上应用Transaction
Script的办法展开开法大约没有其余难题,只要开发人士将世界对象变成“贫血”的“数据载体”对待,在service里已毕业务逻辑,那么该参考架构
将成为纯粹的TransactionScript格局。当然反过来看,那也反映了这一架构的灵活性。确保世界驱动设计的落到实处与实践须求整个集体在条分缕析、设
计和开销上尚未前后地以世界模型为骨干开展工作,以面向对象的思辨进行规划和编程,才能确保落实世界驱动设计。

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中最常见的一类设备是目的持久化的求实完结。

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并非是一种不能够不的零部件。

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

在引入DTO后,DTO与世界对象之间的相互转换工作多由Assembler承担,因而Assembler大约总是同
DTO一起出现。也有一对系统选择反射机制自动已毕DTO与世界对象时期的相互转换,Appache的CommonsBeanUtils就提供了近乎的效果。应该说那二种已毕各有利弊,使用Assembler进行对象数据互换更为安全与可控,并且接受编译期检查,不过代
码量分明偏多。使用反射机制自动进行象数据互换纵然代码量很少,但却是卓殊薄弱的,一旦目的属性名暴发了转变,数据交互就会破产,并且很难追踪发现。总体
来说,Assembler更为直白和妥善。

图片 8

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

有关Assembler具体的宏图用意和拔取场景可参考如下资源:

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

2.《Patterns of Enterprise ApplicationArchitecture》

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
Services、RMI或Rest等在内的一种或多样通讯接口。该层主要由Façade、DTO和Assembler三类组件构成,三类组件均是独立的
J2EE情势,以下是对三类组件的切实可行介绍:

摘要

本文将介绍世界驱动设计(Domain Driven
Design)的法定参考架构,该架构分为了Interfaces、Applications和Domain三层以及带有各样基础设备的
Infrastructure。本文种对架构中有的要害组件和难点展开座谈,给出一些分析结论。

相关文章

网站地图xml地图