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

软件开发要干什么:web

 

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

 

领域Domain网络

 

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

 

 领域建模数据结构

领域模型驱动设计架构

}  分层架构框架

}  实体.net

}  值对象设计

}  服务版本控制

}  模块对象

}  聚合接口

}  工厂

}  资源库

 

分层架构:

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

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

}  复杂的程序切分红层

}  层中采用内聚的设计

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

 

实体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  面向服务的架构

相关文章
相关标签/搜索