DDD领域让设计(Domain Driven Design)(转)领域让设计(DDD:Domain-Driven Design)转。

摘要

本文将介绍世界让设计(Domain Driven
Design)的合法参考架构,该架分为了Interfaces、Applications和Domain三层与含有各类基础设备的
Infrastructure。本文会指向架构中一些生死攸关器件和题材进行讨论,给闹有些剖析结论。

出处:http://blog.csdn.net/johnstrive/article/details/16805121
征:找了多稿子,看上去就像哲学论文一样,并无能够懂得(看来还是要执行备受领悟了)。不过这首文章于自己看明白一个约的意,所以记录转。

目录

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。下图简略描述了它们之间的涉及:

lovebet 1

希冀1:领域让设计风格的架草图(来自于DDDSample官网)

下图是事无巨细架构:

lovebet 2

祈求2:领域让设计参考架构

作参照,下图展示了传统TransactionScript风格的架,可以看看,两者的反差并无是极其怪(对于Façade来说,它是一样种植而选设
施,如果系统架构中省略Façade,则DTO与天地对象的互换工作可于service中进行),这吗从则面说明履行领域让设计之基本点并无在架设上,而
在于所有集体在条分缕析、设计及出上尚无前后地盖世界模型也着力开展工作,以面向对象的思考进行统筹与编程。

Transaction
Script风格的架构具有明确的“数据”与“操作”分离的特色,其同世界让设计风格的架在有限单近乎组件上有质的区别,一个凡圈子对象,一个是
Service。领域让设计之架构核心目标是一旦开创一个富裕领域模型,其一流特征是她的领域对象有丰富的事情方法用以处理事情逻辑,而
Transaction
Script风格的园地对象则仅仅是数额的载体,没有事情方法,这种领域为吃称呼“贫血的小圈子对象”(Anemic
Domain
Objects)。在Service方面,领域让设计的架里Service是充分“薄“的如出一辙叠,其并无顶处理事情逻辑,而以
TransactionScript风格的架里,Service是拍卖业务逻辑的关键场合,因而往往非常重。

lovebet 3

图3:数据以及操作分离的Transaction Script风格的架

=

反映实际世界要自动化的业务流程
化解具体问题

2.      架构详解

领域Domain

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特指软件关注的园地
于非能够尽量了解工作领域的图景下是勿可能做出一个好的软件

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

贪图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的Commons
BeanUtils就提供了类似的作用。应该说这有限栽实现各有利弊,使用Assembler进行对象数据交换更为安全以及可控,并且接受编译期检查,但是代表
码量明显偏多。使用反射机制自动进行象数据交换虽然代码量很少,但可是老薄弱的,一旦目标属性名发生了变通,数据交互就会见砸,并且充分为难追踪发现。总体
来说,Assembler更为直白和妥善。

lovebet 5

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

关于Assembler具体的规划用意和动场景可参考如下资源:

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

2.《Patterns of Enterprise ApplicationArchitecture》

lovebet 6

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.

lovebet 7

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

lovebet 8

希冀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》

lovebet 9

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。

lovebet 10

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

Service的接口是面向用例设计之,是控制作业、安全之方便场所。如果Façade的某部同术要调用两只以上的Service方法,需要小心工作问题。

lovebet 11

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(仓储)等强根本之小圈子组件。

lovebet 12

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.      关于架构的有些讨论   

分段架构:

3.1.    架构并无能够保证领域让设计之兑现与执行

虽一个适度的架对于推行世界让设计是可怜出必要的,但唯有靠架构是匪可知管领域让设计的实现和履行之。实际上,在
这个参考架构上利用Transaction
Script的办法展开开法几乎从不另外问题,只要开发人员将世界对象变成“贫血”的“数据载体”对待,在service里实现工作逻辑,那么该参考架构
将成纯粹的TransactionScript方式。当然反过来看,这也体现了就等同架的油滑。确保世界让设计的贯彻和实践得全集团以解析、设
计和支付上未曾始终地以世界模型也主导开展工作,以面向对象的思辨进行规划以及编程,才会管落实世界让设计。

lovebet 13

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并非是平种要的组件。

}
将世界模型相关的代码集中到一个层中,把她从用户界面、应用及基本功设备代码中隔开来
}
释放领域对象的展示自己、保存好、管理下任务等任务,让它们小心于表现领域模型
} 复杂的次序切分成层
} 层中利用内聚的筹划
} 层仅指让它底下的那么层

lovebet 14

实体entity:发平等近乎对象有唯一标识符
} 能够过系统的生命周期甚至会跳软件系统的同多元之延续性和标识符
} 这样的靶子称为实体。
值对象-value Object
} 对某个对象是啊不感兴趣,只关注她抱有的特性
} 用来叙述领域的特别方面、且无标识符的一个靶,叫做值对象
} 能被简单的始建及废弃,生命周期中莫会见受持久化
} 值对象好给共享,值对象应该不可变
服务-service(比webservice更周密粒度服务描述)
} 领域被之有的动词,代表了世界中的一个至关重要的所作所为,却无属另外对象

服务实践之操作涉及一个领域概念,这个世界概念一般不属一个实体或者值对象
◦ 被实践之操作涉及到世界被的别样的目标
◦ 操作是管状态的
} 服务对象不再具有内置的状态
} 服务对象lovebet承担重要的调和效应
}
开发通用语言时,领域被之主要概念让引入到语言中,语言中之名词很轻为映射成对象。
语言中针对许那些名词的动词变成那些对象的行为。但是小领域面临之动作,它们是一些动词,看上去也无属其他对象。它们代表了世界被之一个关键的行,所以无克忽视她要略的把它统一到某个实体或者值对象吃。给一个目标多这样的作为会摔之目标,让它们看上去有了应该属于她的功用。

模块
} 将相关领域模型提炼分类,分而治之
}
将高关联度的模型分组到一个模块以供尽可能大之内聚(以会完全完成任务为仍)
} 分层是水平划分
} 模块是直细分(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、RMI或Rest等在内的一律种植或多通信接口
}
该层主要出于Facade、DTO和Assembler三类组件构成,三类似组件都是超人的J2EE模式
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层是任何体系的基本层,该层维护一个使面向对象技术实现之小圈子模型,几乎全底事体逻辑会在该层实现
} Domain层包含:
◦ Entity(实体)
◦ ValueObject(值对象)
◦ Domain Event(领域事件)
◦ Repository(仓储)等
Infrastructure-基础设施层

lovebet 32

} 基础设备层nfrastructure为Interfaces、Application和Domain三叠提供支持
}
所有和具象平台、框架相关的落实会晤在Infrastructure中提供,避免三叠特别是Domain层掺杂进这些实现,从而“污染”领域模型
} Infrastructure中极度常见的一模一样好像设施是目标持久化的有血有肉落实
“传统”架构-贫血领域模型

lovebet 33

DDD && SOA
} DDD 领域模型驱动设计
} SOA 面向服务的架