领域驱动设计实例讲解

Domain Driven Design ——GAP平台领域驱动设计

演讲人：ITARI

日期：2009-09-15

Book Store：GAP的DDD应用

GAP平台的领域驱动设计

事务脚本和领域模型

领域驱动简介

A. 什么是DDD

B. DDD的分层架构�

C. DDD的基本构成要素�

大纲

 领域驱动设计

什么是DDD(1)

2004年著名建模专家Eric Evans发表了他最具影响力的著名

书籍：《Domain-Driven Design –Tackling Complexity in

the Heart of Software》（中文译名：领域驱动设计—软件

核心复杂性应对之道），书中提出了“领域驱动设计(简称

DDD)”的概念。 �

 领域驱动设计

什么是DDD(2)

领域驱动设计事实上针对是OOAD的一个扩展和延伸，

DDD基于面向对象分析与设计技术，对技术框架进行了分层

规划，同时对每个类进行了策略和类型的划分。 �

领域模型是领域驱动的核心，采用DDD的设计思想，业

务逻辑不再集中在几个大型的类上，而是由大量相对小的领

域对象（类）组成，这些类具备自己的状态和行为，每个类

是相对完整的独立体，并与现实领域的业务对象映射。领域

模型就是由这样许多的细粒度的类组成。基于领域驱动的设

计，保证了系统的可维护性、扩展性和敏捷性，在处理复杂

业务逻辑方面有着先天的优势。 �

•  成熟、清晰的分层架构

•  领域对象与现实世界的业务映射

•  明确的职责划分�

分层架构�

•  领域对象是核心

•  领域对象复用：完整的业务对象描述

•  设计复用：设计基于领域对象而非数据库�

复用�

使用场景�

•  具备复杂业务逻辑的软件开发

•  对设计和开发人员要求较高

•  不适用普通CRUD的业务

•  软件的维护性和扩展性良好�

DDD的特性

 Design without DDD:

不使用DDD会如何呢？

不去建立和开发领域模型，会导致应用架构出现“胖服务

层”和“贫血的领域模型”，在这样的架构中，Service层开始积聚越

来越多的业务逻辑，而领域对象则成为只有getter和setter方法的数

据载体。这种做法还会导致领域特定业务逻辑和规则散布于多个的

Service类中，有些情况下还会出现重复的逻辑 �

在大多数情况下，贫血的领域模型没有成本效益；它们不会给

公司带来超越其它公司的竞争优势，因为在这种架构里要实现业务需

求变更，开发并部署到生产环境中去要花费太长的时间 �

DDD的分层架构(1)

DDD的分层架构(2)

用户界面/展现层负责向用户展现信息以及解释用户命令。

应用层 � 很薄的一层，用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态，但它保有应用任务的进度状态。

领域层 � 本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层。

基础设施层 � 本层作为其他层的支撑库存在。它提供了层间的通信，实现对业务对象的持久化，包含对用户界面层的支撑库等作用。

DDD的领域模型架构（Ref POJO in action）

 领域驱动设计对Object做了明确的职责和策略划分

DDD的基本构成要素(1)

  Entities：Objects with a distinct identity；实体类，具备唯一ID，持久化，具备业务逻辑，对应现实世界业务

  Value objects：Objects with no distinct identity；内存中的对象，传参，和实体类的比较方式不同

  Factories：Define methods for creating entities，工厂类，可用来创建多个实体

  Repositories：Manage collections of entities and encapsulate the persistence framework；持久化层，DAO

  Services：Implement responsibilities that can’t be assigned to a single class and encapsulate the domain model；服务层，为上层提供操作的接口，负责对领域对象进行调度和封装，同时可以对外提供各种形式的服务

DDD的基本构成要素(2)




领域驱动简介

大纲

A. 事务脚本

B. 领域模型

 使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求

事务脚本模式(Transaction Script)

 大部分业务应用都可以被看成一系列事务  在某些情况下，业务处理会像直接处理数据库信息一样简单，例如CRUD

 事务脚本将这些所有的业务逻辑组织成单个过程，在过程中直接调用数据库，如有业务逻辑在Service层处理

 事务脚本的特点：简单容易理解，面向过程设计

事务脚本模式(使用场景)

 对于少量逻辑的业务应用来说，事务脚本模式非常简单自然，性能良好，容易理解

 代码生成器生成的程序基本都是事务脚本模式  一个事务的处理不会影响其他事务  缺点也很明显，对于复杂的业务逻辑处理力不从心，难以保持良好的设计，事务之间的冗余代码不断增多，通过复制粘贴方式进行复用，可维护性和扩展性变差

领域模型(Domain Model)

 面向对象设计  领域模型具备自己的属性行为状态，并与现实世界的业务对象相映射

 明确的职责划分，各个领域对象元素配合解决实际业务应用和规则

 复用性，可维护性，扩展性  设计模式的应用  缺点：相对复杂，性能问题

领域模型(复杂应用)




领域驱动简介

大纲

A. GAP分层架构

B. GAP DDD要素�

C. 如何构建领域应用

GAP平台的分层架构(1)

GAP平台的分层架构(2)

  View：展示层，由于GAP平台主要面向B/S架构，展示层主要由web资源文件组成，包括JSP，JS和大量的界面控件，采用了AJAX技术，负责向用户展现丰富的界面信息，并执行用户的命令

  Control：控制层，负责展示层请求的转发、调度和验证，同时处理后台返回的异常信息，同时控制层可以通过Action做远程的请求

  Domain：领域层，是系统最为丰富的一层，主要负责处理整个系统的业务逻辑。这一层主要包括业务服务和领域模型，同时负责系统的事务管理

  Persistence：持久化层，主要负责数据持久化，支持O/R Mapping和JDBC，对数据源的访问提供多种访问方式。

系统的控制层、领域层和持久化层元素都有IOC容器统一管理，实现完全的接口分离和解耦。

GAP平台领域驱动设计要素(1)

GAP平台领域驱动设计要素(2)

  业务服务：遵循GAP平台的设计思想，架构核心是业务服务(Business Service)，一个业务服务可以由一个或多个领域模型和数据访问对象(DAO)组成，去完成一个完整的业务逻辑单元。业务服务主要负责事务处理和维护各个领域对象之间的关系，同时为上层访问提供服务。

  领域模型：真正处理业务逻辑的类，例如订单(OrderModel)，具备自己的属性和行为、状态，可以聚合VO和Entity，持久化数据可以委托给Entity，如果没有聚合Entity，也可以直接被持久化。

  实体类：只具备需要持久化的属性，被领域对象聚合，被DAO调用实现数据的持久化。如果业务逻辑相对简单，可以合并到领域模型中。

  值对象：不具备唯一标识，不进行持久化的对象，一般用来进行参数传递。

  数据访问对象：不处理业务逻辑，主要负责领域模型或实体类的持久化。提供多种持久化方式。

注：基于现有的GAP应用，实体类和值对象可以统一以VO为后缀进行命名

如何在GAP平台中实现一个领域模型设计

 确定业务服务（Business Service），根据业务需求和功能模块划分，确定业务单元，每个Business Service是一个业务单元，覆盖相关的领域对象。

 定义领域对象（Domain Model，VO，Entity），根据业务单元的业务逻辑定义领域对象，通过UML方法和设计模式描述领域对象。

 定义领域对象的属性和关联关系，确定领域对象的各种属性和各个领域对象之间的关联关系

 为领域对象增加行为，根据业务需求（系统用例和界面原型等）为领域对象增加行为，并定义哪些方法要被业务服务所用




领域驱动简介

大纲

 Design with DDD:

Book Store-GAP的DDD应用

网上书店系统是“用领域驱动设计(Domain Driven Design)思

想设计应用系统”的一个示例。通过网上书店系统，可以快速理解领

域驱动设计。 �

本系统实现网上书店的常用功能：包括浏览书籍、挑选书籍、

提交订单、查看订单、自动折扣、处理订单、取消订单等。未登录用

户可以浏览和挑选书籍；已登录用户可以提交和查看自己相关的订单；

管理员可以处理订单。 �

 Package:


Book Store-GAP的DDD应用  Domain Model:

 订单(Order)：

Book Store的领域模型

 订单的实现类是gap.template.bookstore.model.Order，类中除了联系方式、邮寄地址等基本信息外，还有以下领域相关的行为：

  init(Account account,List newItems)，结算时调用方法，根据当前用户与购物车中的Items初始化订单，供用户修改。

  submit(IBookStoreDao dao,List newItems)，提交订单时调用的方法，保存订单。

  cancle(IBookStoreDao dao)，取消订单，把订单和相关item的状态设置为“已取消”，然后委托dao进行持久化。

  dispose(IBookStoreDao dao)，管理员处理订单。在service中，首先会通过Acount领域对象的payment方法进行余额校验，如果校验通过，就会调用订单对象的dispose方法处理订单。

 订单(Order)：


 账户(Accoun)：


 账户的实现类是gap.template.bookstore.model.Account，类中除了账户名、密码、余额等常用信息外，还有领域相关的行为。

  payment(IBookStoreDao dao,BigDecimal price)，此方法的功能是付款。在管理员处理订单时，首先获得订单金额，把金额交给账户领域对象，由它去做业务验证(判断余额是否足够)，如果以后需要改变判断余额的业务逻辑，直接修改领域对象即可。如果业务验证通过，则把持久化领域对象的工作委托给传进去的dao。

  augmentMoney(BigDecimal moeny)，此方法的功能是为账户充值，方法接收要充值的金额。与付款行为不同，此处持久化领域对象的行为由调用该对象的service完成。

  setDiscount，isAdmin

 账户(Accoun)：


 购物车(Cart)：


 购物车领域对象是用户挑选书籍到提交订单期间的临时存储结构，不会被持久化，对象内聚一个类型为ItemVO(保存书籍信息和书籍数量的javabean)的List对象。

  addItem(ItemVO item)，往购物车中添加书籍条目。   removeItem(ItemVO item)，从购物车中删除书籍条目。   removeItemByBookId(String bookId)，购物车中只能通过

item中book对象的bookId来定位item，所以需要根据bookId来删除item。

 购物车(Cart)：



Service

领域驱动设计-总结

与您共赢未来�

地址 : 北京市海淀区北清路68号用友软件园A座 (100094) 电话 : 86-10-62431717 传真 : 86-10-62431800 电子邮件: [email protected]

个性化 IT 服务�TM

Documents

领域驱动设计实例讲解