领域模型驱动设计(Domain Driven Design)入门概述

软件开发要干什么:

  • 反映真实世界要自动化的业务流程
  • 解决现实问题

领域Domain

  • Domain特指软件关注的领域
  • 在不能充分了解业务领域的情况下是不可能做出一个好的软件

领域建模

领域模型驱动设计

}  分层架构

}  实体

}  值对象

}  服务

}  模块

}  聚合

}  工厂

}  资源库

分层架构:

}  将领域模型相关的代码集中到一个层中,把它从用户界面、应用和基础设施代码中分隔开来

}  释放领域对象的显示自己、保存自己、管理应用任务等职责,让它专注于展现领域模型

}  复杂的程序切分成层

}  层中采用内聚的设计

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

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

}  能够跨越系统的生命周期甚至能超越软件系统的一系列的延续性和标识符

}  这样的对象称为实体。

值对象-value Object

}  对某个对象是什么不感兴趣,只关心它拥有的属性

}  用来描述领域的特殊方面、且没有标识符的一个对象,叫做值对象

}  能被简单的创建和丢弃,生命周期中不会被持久化

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

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

}  领域中的一些动词,代表了领域中的一个重要的行为,却不属于任何对象

?      服务执行的操作涉及一个领域概念,这个领域概念通常不属于一个实体或者值对象

?      被执行的操作涉及到领域中的其他的对象

?      操作是无状态的

}  服务对象不再拥有内置的状态

}  服务对象担当重要的协调功能

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

语言中对应那些名词的动词变成那些对象的行为。但是有些领域中的动作,它们是一些动词,看上去却不属于任何对象。它们代表了领域中的一个重要的行为,所以不能忽略它们或者简单的把它们合并到某个实体或者值对象中。给一个对象增加这样的行为会破坏这个对象,让它看上去拥有了本该属于它的功能。

模块

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

}  将高关联度的模型分组到一个模块以提供尽可能大的内聚(以能完整完成任务为准)

}  分层是水平划分

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

参考架构概述

}  领域驱动设计(DomainDriven Design)有一个官方的sample工程,名为DDDSample

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

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

架构概述

详细架构

架构详解:Interfaces-接口层

}  该层包含与其他系统进行交互的接口与通信设施,在多数应用里

}  可能提供包括WebServices、RMI或Rest等在内的一种或多种通信接口

}  该层主要由Facade、DTO和Assembler三类组件构成,三类组件均是典型的J2EE模式

DTO

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

}  DTO设计之初是为了将细粒度的领域对象包装为粗粒度的数据结构,减少网络通信并简化调用接口

DTO 作用

}  减少网络流量

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

}  传输更多的数据减少远程调用次数

}  避免将领域状态跨层次传递

}  由于同步和版本控制增加了复杂性

DTO 应用时序图

Assembler

}  DTO与领域对象之间的相互转换工作多由Assembler承担

}  因此Assembler几乎总是同DTO一起出现。

Assembler 实现方案

Façade

}  实践Facade的过程中最难把握的问题就是Facade的粒度问题。

}  传统的Service均以实体为单位进行组织,而Facade应该具有更粗粒度的组织依据,较为合适的粒度依据有:

}  一个高度内聚的模块一个Facade

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

Facade 实现方案

Facade 应用时序图

Service

}  Service会与多种组件进行交互

}  这些组件包括:

?      其他的Service

?      领域对象

?      Repository

?      DAO

Service 应用时序图

Domain-领域层

}  Domain层是整个系统的核心层,该层维护一个使用面向对象技术实现的领域模型,几乎全部的业务逻辑会在该层实现

}  Domain层包含:

?      Entity(实体)

?      ValueObject(值对象)

?      Domain Event(领域事件)

?      Repository(仓储)等

Infrastructure-基础设施层

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

}  所有与具体平台、框架相关的实现会在Infrastructure中提供,避免三层特别是Domain层掺杂进这些实现,从而“污染”领域模型

}  Infrastructure中最常见的一类设施是对象持久化的具体实现

“传统”架构-贫血领域模型


DDD && SOA

}  DDD 领域模型驱动设计

}  SOA  面向服务的架构

http://blog.csdn.net/johnstrive/article/details/16805121

时间: 2024-10-23 16:12:18

领域模型驱动设计(Domain Driven Design)入门概述的相关文章

领域驱动设计(Domain Driven Design)参考架构详解

转自:http://blog.csdn.net/bluishglc/article/details/6681253 领域驱动设计(Domain Driven Design)参考架构详解 摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.

[转载]领域驱动设计(Domain Driven Design)参考架构详解

摘要 本文将介绍领域驱动设计(Domain Driven Design)的官方参考架构,该架构分成了Interfaces.Applications和Domain三层以及包含各类基础设施的Infrastructure.本文会对架构中一些重要组件和问题进行讨论,给出一些分析结论.本文原文连接:http://blog.csdn.net/bluishglc/article/details/6681253 转载请注明出处! 目录 1.      架构概述2.      架构详解        2.1.  

什么是领域驱动设计(Domain Driven Design)?

本文是从 What is Domain Driven Design? 这篇文章翻译而来. ”…在很多领域,专家的作用体现在他们的专业知识上而不是智力上.“ -- Don Reinertsen 领域驱动设计(Domain Driven Design)是一种软件开发方法,目的是让软件系统在实现时准确的基于对真实业务过程的建模并根据真实业务过程的调整而调整. 传统的开发工作趋向于一种以技术为先导的过程,需求从业务方传递到开发团队,开发人员依据需求上的描述创造出最有可能的假想. 在瀑布开发过程中,这导致

[译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块

本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章地址: [译文]Domain Driven Design Reference(一)—— 前言 [译文]Domain Driven Design Reference(二)—— 让模型起作用 [译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块 Ⅱ.模型驱动设计的

状态模式在领域驱动设计中的使用(Using the State pattern in a Domain Driven Design)

领域驱动设计是软件开发的一种方式,问题复杂的地方通过将具体实现和一个不断改进的核心业务概念的模型连接解决.这个概念是Eric Evans提出的,http://www.domaindrivendesign.org/这个网站来促进领域驱动设计的使用.关于领域驱动设计的定义,http://dddcommunity.org/resources/ddd_terms/,这个网站有很多的描述,DDD是一种软件开发的方式: 1.      对于大多数的软件项目,主要的精力应该在领域和领域的逻辑. 2.     

[译文]Domain Driven Design Reference(四)—— 柔性设计

本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章地址: [译文]Domain Driven Design Reference(一)—— 前言 [译文]Domain Driven Design Reference(二)—— 让模型起作用 [译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块 [译文]Domai

[译文]Domain Driven Design Reference(六)—— 提炼战略设计

本书是Eric Evans对他自己写的<领域驱动设计-软件核心复杂性应对之道>的一本字典式的参考书,可用于快速查找<领域驱动设计>中的诸多概念及其简明解释. 其它本系列其它文章地址: [译文]Domain Driven Design Reference(一)—— 前言 [译文]Domain Driven Design Reference(二)—— 让模型起作用 [译文]Domain Driven Design Reference(三)—— 模型驱动设计的构建模块 [译文]Domai

Domain Driven Design and Development In Practice--转载

原文地址:http://www.infoq.com/articles/ddd-in-practice Background Domain Driven Design (DDD) is about mapping business domain concepts into software artifacts. Most of the writings and articles on this topic have been based on Eric Evans' book "Domain Dr

DDD(Domain Driven Design) 架构设计

一.为什么要分层 分层架构是所有架构的鼻祖,分层的作用就是隔离,不过,我们有时候有个误解,就是把层和程序集对应起来,就比如简单三层架构中,在你的解决方案中,一般会有三个程序集项目:XXUI.dll.XXBLL.dll 和 XXDAL.dll,然后把这三个程序集看成一个层,这没什么不可以,但当项目复杂的时候,如果还按照这种方式的话,你的程序集中的文件夹会越来越多,程序集也会越来越大.当你的视野跳出这个程序集的概念后,你会发现,层不只是和程序集对应,也和解决方案文件夹,或者是整个解决方案对应,一个层