实战DDD(Domain-Driven Design领域驱动设计:Evans DDD)

面向对象与领域建模
板桥里人http://www.jdon.com 2006/12/6(转载请保留)

如果没有多变的需求,也许就没有今天的面向对象软件,我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击,可是这样下去的结果只有一个:使得软件更加僵化;或者程序员更加 劳累。

  需求不但多变,而且经常是不可能第一次就能掌握,需求反映了某个领域的专业知识,例如数学、管理、财务或 电子商务等等,每个特定案例需求又有其特别复杂之处,几乎没有人能够第一次接触就可以深入掌握这些专业领域的 需求本质,就是专门的建模专家也不例外。

  既然需求是多变而且复杂的,所以,就不能使用“堵”式方法对其进行控制和管理,只能顺势而为,通过灵活多变的 以及迭代反复的方式逐步抓住需求,并且作为需求的实现软件系统必须能够迅速应对需求变化,需求变化有多快,软件 变化就有多快。

  因此,对于多变的需求,我们的解决之道是:引入灵活多变的架构,面向对象OO架构正是应对多变需求而生,强调软件的可维护性 和拓展性,OO可能不是最好方式,但是目前是最合适的;对于复杂的需求,我们的解决之道是:委派专门的建模专家跟踪理解需求, 在需求和需求实现之间搭建桥梁,项目方法上采取多次迭代的敏捷软件开发方式,逐步了解学习掌握需求。

  在这里稍微说明一下,很多人总是将软件和数学、管理、财务混为一谈,其实软件本身就是一门独立的专业,是为 数学、管理。财务等专业领域服务的,不能期望软件人员也是其他领域专业人员,可是在中国现实中,很多人总是 无法分辨,例如某局长将整个机关考核信息化的任务交给电脑中心,这就是将考核管理专业和软件专业混同的例子, 在考核管理和软件之间需要一个领域建模专家,由他来理解或者设计考核管理体系,然后通过模型,表达成 软件人员能够看懂的符号,软件人员通过模型了解领域。

  曾经有需求专家呼吁:最好将需求给所有软件人员都了解,需求专家和一般软件人员一起工作,这些想法的本质是 好的,但是不可能实现的,不可能每个软件人员不但了解软件架构和OO思想;还能够掌握另外一个专业领域的艰深知识, 所以,现在我们提出:将领域专家建立的统一领域模型让所有软件人员都了解,让一般软件人员围绕领域模型工作,这样 的方式才切实可行。

需求分析方法演变

  历史上,对需求分析方法可以说经过三个阶段:

  第一阶段:围绕数据库的驱动的分析设计,新软件项目总是从设计数据库及其字段开始。这个阶段特征就是围绕数据库编程,典型的是 DBase/Foxpro,以及后来的Delphi/VB技术。

  这种围绕数据库分析设计的缺点非常明显:首先,不能迅速有效全面认识反映需求,世界不只是由简单的关系数据组成,而且 使用关系数据来反映现实需求,不符合人类自然思维(OO才是),是一种扭曲的分析方法,特别对于初学者,他们接受数据库分析方法的难度反而可能会大于OO分析方法,现在很多职业学校和社会培训,基础课程从数据库开始,从某种程度上,是历史倒退, 严重阻碍中国软件发展的进程。

  围绕数据库分析极其容易导致过程化设计编程,围绕数据分析和过程化编程是一对恶魔,数据库结构确立后,就让普通程序员写SQL 语句,SQL语句执行有明显的先后顺序,在这样顺序过程编程思维中,OO思维就难以生存。长此以往,成为习惯后,就很难改变到 OO设计上,所以,传统编程经验越丰富,转变到OO设计就越难。

  在运行性能方面:围绕数据库分析设计容易导致软件运行时负载集中在数据库端,系统性能难于扩展(走上集中式、昂贵的、高风险的大型机模式), 闲置了中间件J2EE服务器分布式集群处理能力,就是使用了集群,也分担不了负载。

  最后,我们必须认识到:对象和关系数据库存在阻抗,本身是矛盾竞争的,他们是两种分析看待需求的流派,可以说是水火不容, 要么你采取数据库分析设计以及过程化编程,要么完全采取OO,现在使用.NET和Java这样OO语言的人很多,但是70%左右都是使用OO语言
编写传统过程化系统,在Java中这样做,会有极差性能;而这种现象在.NET中又极容易得到纵容,.NET是一个系列阵营,正如Windows系列一样, 当你和别人说,你在使用Windows,别人可能觉得你没有落后时代,但是他们哪里知道你在使用Windows 3.1呢?

  第二阶段:面向对象的分析设计方法诞生后,有了专门的分析和设计阶段之分,我们使用UML符号来表达分析设计思想,分析设计进入了一个相对更高的层次,拥有了自己一套科学且艺术的方法论。但是有一个致命缺点:分析阶段和设计阶段是断裂的,互相不能很好衔接,为什么?

  首先,我们看看分析人员和设计人员在职责重点工作是什么?
  分析人员的职责:是负责从需求领域中收集基本概念。而设计人员的职责:必须指明一组能北项目中适应编程工具构造的组件,这些组件必须能够在目标环境中有效执行,并能够正确解决应用程序出现的问题 两个阶段两者目标不一致,分析人员只管需求分析,至于是否适合设计,或者能够导出适宜设计的分析结果,这个尺度很难衡量和把握;

  而设计人员因为照顾代码可运行,因此,经常可能会抱怨分析员给出的结果过于粗糙,不适合设计,这样分析设计两个阶段就导致分裂,项目失败。

  在这个阶段,虽然有UML帮助,但是UML不是思想,打个比喻:会CAD的绘图员就是建筑师吗?很显然,UML就是CAD图符号,UML不等于分析设计思想。 所以,有人说UML不是银弹,这些就象说中医不是科学一样绕人(中医就不是西医,当然就不是科学)。

  第三阶段:融合了分析阶段和设计阶段的领域驱动设计(Evans: DDD)。2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计 )简称Evans DDD, 领域建模是一种艺术的技术,它是用来解决复杂软件快速应付变化的解决之道,所以,从Evans DDD通篇文章中,你找不到科学象征的定理和公式,当然如果 你试图寻找这样寻找,你也就陷入了“中医是不是科学”怪圈了。

  Evans DDD抛弃了分裂分析模型与设计的做法,使用单一的模型来满足这两方面的要求。这就是领域模型。 单一的领域模型同时满足分析原型和软件设计 ,如果一个模型实现时不实用,重新寻找新模型。如果模型没有忠实表达领域关键概念时,也必须重新寻找新的模型。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此,建模专家必须懂设计。


领域建模的重要性

  如果你说一个软件开发需要经过需求、分析和设计三个阶段的话,那么可能反映你的思想已经落伍,软件开发现在是 经过需求、建模阶段,混合了分析和设计阶段,可以更激进地说:我们国家的系统分析员和系统设计员考试也许应该合并了, 合并成建模专家的考试,否则,这些都是中国软件落后世界十年的证据,可悲的是:我们自己可能都不知道。

  Evans DDD可以说是近期与SOA相提并论的两大重要技术思想,SOA是着重于软件集成方面;而EvansDDD才是着重我们软件开发上, 在大部分情况下,软件开发重要程度不亚于软件集成,但是因为软件开发方面开源力量冲击,软件集成上工业厂商利润最高, 所以,工业厂商在SOA叫得最响,我们参加得各种会议几乎都是SOA,当心被误导,工业厂商从来不会告诉你事实得争相。

   没有面向对象的分析设计,哪里面向对象的构件或组件?过去经验不是证明:我们使用大量的构件组件,却在编制面向过程的体系?

  以EJB2为例子,在EJB2过去大部分系统中,我们常常以数据库为中心,实体Bean因为特殊技术原因,僵硬一块,变成数据库 的代名词,我们围绕实体Bean编制出大量的值对象Vale Obejct,或称为DTO(Data Transfer Object),在这样系统中,从对象 的名称也可以看出,对象是为数据服务的,对象从属于数据库的。

  现在,要彻底改变过来,OO就是以对象为主,数据库是从属对象设计的,如果说EJB2的实体bean技术让你不得不走上传统过程化编程歧路,那么 EJB3已经更正了实体Bean设计缺陷,从EJB发展可以看到一个侧面:工业厂商更多关心的是功能,而不是设计?

  只有谁才真正关心你的软件设计和代码质量?只有你自己。我不是提倡都不要参加工业厂商的会议,而是需要每个人冷静想想: 到底谁是自己代码的主人?

  领域建模属于与具体.NET或Java技术无关的设计思想,有人总是说:.NET比Java简单,其实这又是一个大误区,如果都达到同样设计水准,无论使用.NET或Java,都需要付出同样的努力;那为什么有人觉得.NET简单,那是因为设计要求降低了,参见这篇.NET的DDD文章。

分层架构

  分层架构是现代OO软件企业系统的基本架构,只有分层才能达到良好的可拓展性和维护性。基本三层:表现层、业务层和持久层 ;J2EE中表现层和持久层有成熟框架支持,应用重点在业务层。

  业务层根据Evans DDD,可以再细分为应用层和领域层两种,在业务层设计编码中,大量应用OO设计原则和设计模式。领域层定义:负责表达业务领域概念、业务状态以及业务规则,是整个业务软件核心和重点。 应用层定义:负责完成功能,并且协调丰富的领域对象来实现功能,不能包括业务规则,无业务状态;

  每个层都是内聚的,并且只依赖它的下层,为了实现各层的最大解耦,IOC/DI容器是当前Java业务层的最好选择 。

   没有分层架构的快速开发基本是旁门左道,不如返回Foxpro和Delphi/VB两层时代。将本属于业务层的逻辑交由表现层来处理的快速UI方式也是一种旁门左道。快速开发必须基于良好的质量,虽然良好的分层架构带来开发效率的降低,但是这些也是可以有方法解决。

建模与项目管理

   在我们大多数从软件项目管理上寻找软件永恒解决之道时,他们可能没有意识到又在范“缘木求鱼”老毛病了, 打个比喻很容易明白这个道理:冷兵器时代(也就是火枪没有没有发明之前),各种排兵布阵可能在作战指挥时 很有效;但是到了火器时代,所有的过去作战方式就落伍了;当然到了现在信息化战争时代,更是天壤之别。

   Evans DDD领域驱动建模的诞生,对过去传统的项目管理都提出挑战,当我们还在争论RUP好还是敏捷好的时候, 谁会想到我们应该采取围绕统一领域模型的迭代驱动开发呢?

   有人可能还在疑惑?我接到一个大项目,那么我的建模和架构设计时间应该是5个月还是5年呢?当然应该回答他:都不行,需求是多变且复杂的,计划赶不上变化,现在就应该开始DDD建模。

2004年著名建模专家Eric Evans发表了他最具影响力的著名书籍:Domain-Driven Design –Tackling Complexity in the Heart of Software(中文译名:领域驱动设计 2006年3月清华出版社译本,或称 Domain Driven-Design architecture [Evans DDD])。

  Martin Fowler作序说;“希望本书是一本非常有影响力的书籍,....... Eric最值得我尊敬的一个方面是他敢于讨论还未取得成功的事情”,其实,时值今年2006年,DDD开发框架已经层出不穷(如RoR、RIFE、JdonFramework等),我们项目软件包结构都变成了这样:xxx.model;xxx.service,DDD思想已经遍地开花,不能再说不成功了。

  DDD是告诉我们如何做好业务层!并以领域驱动设计思想来选择和合适的框架,本文以基于JdonFramework开发的JiveJdon3.0说明DDD方法的实战应用。

  首先必须认识到:领域建模是一种艺术的技术,不是数学的技术,它是用来解决复杂软件快速应付变化的解决之道(快速适应需求变化的软件复用)。

  我们知道软件的产生过程是:分析、设计、编程、测试、部署。过去,分析领域和软件设计是分裂的,分析人员从领域中收集基本概念;而设计必须指明一组能北项目中适应编程工具构造的组件,这些组件必须能够在目标环境中有效执行,并能够正确解决应用程序出现的问题。 模型驱动设计(Model-Driven Design)抛弃了分裂分析模型与设计的做法,使用单一的模型来满足这两方面的要求。这就是领域模型。

  单一的领域模型同时满足分析原型和软件设计,如果一个模型实现时不实用,重新寻找新模型。如果模型没有忠实表达领域关键概念时,也必须重新寻找新的模型。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此,建模专家必须懂设计,会编程。

分层架构

  最初层次只分为三层:表现层、业务层和持久层;DDD其实告诉我们如何让实现业务层!

  一位道友曾经请教层次的职责,对服务Service提出疑问。根据Eric的理论,业务层将细分为两个层次:应用层和领域层。它们的定义是:应用层:定义软件可以完成的工作,并且指挥具有丰富含义的领域对象来解决问题,保持精练;不包括业务规则或知识,无业务情况的状态; 领域层:负责表示业务概念、业务状态的信息和业务规则,是业务软件核心。

  层次之间必须清晰分离,每个层都是内聚的,并且只依赖它的下层,为了实现各层的最大解耦,Ioc模式和Ioc容器是目前最好的选择,JdonFramework使用基于PicoContainer的Ioc容器实现了各层的松耦合;

  Eric特别指出:那种将业务逻辑交由业务界面处理的快速UI方式是旁门左道。希望象C/S结构那样可视化拖拖图形就完成的软件开发是一种错误的方向,开发时快速,难于维护和扩展,虽然使用J2EE技术,其实是一种伪多层技术。可惜,有很多国人在疯狂开发这类工具,大有不撞南墙不低头之势,并且疯狂误导很多非专业人士,可悲可叹!如果对这段言论持不同意见,建议你购买"领域驱动设计"这本译书,见P53页。

领域模型种类

  传统模型分为两种:实体(Entity)和值对象(value Object),现在服务(Service)成为第三种模型元素。

  实体(Entity)定义:通过一系列连续性(continuity)和标识(identity ID)来定义;个人认为它和分析领域的四色原型中的PPT原型非常类似,可以看成是PPT原型延续。

  实体必须拥有自己的唯一ID,主键,如果没有一个ID标识,为每个实例加上一个具有唯一性ID,可能是内部使用。 如JiveJdon3.0中jdonframework.xml中模型增删改查CRUD配置定义:

<model key="forumId"  class="com.jdon.jivejdon.model.Forum">
    .....    
</model>

  其中,forumId是模型com.jdon.jivejdon.model.Forum的主键,唯一ID,每个模型必须有一个专家。

  值对象(value Object):如果一个对象代表了领域的某种描述性特征,且没有概念性的标识。个人认为它是四色原型中Description原型延续。如果我们只关心模型中一个元素的属性,那么把这个元素划为值对象。值对象是不可变的,不要给它任何标识,避免实体的维护性,降低设计复杂性。我们不关心值对象是哪个实例。

  在JiveJdon3.0中,ForumState是一个值对象,它表示论坛当前最新帖子、论坛的主题数量和帖子数量,它的根对象是Forum,是被内聚嵌入到Forum这个实体模型中的,代码如下:

package com.jdon.jivejdon.model;




/**
* Forum State valueObject
* this is a embeded class in Forum.
* @author <a href="mailto:[email protected]">banq</a>
*
*/
public class ForumState {

  private int threadCount = 0; //主题数量

  
  private int messageCount = 0;//帖子数量


  private ForumMessage lastPost; //最新帖子



  public int getMessageCount() {
    return messageCount;
  }  

  ......
}
  同样ForumThreadState是也是一种值对象,根据Eric的值对象设计,ForumThreadState和ForumState是可以合并成一个对象的,值对象中没有ID等唯一标识。

Eric认为:服务Service是描述领域概念最自然的方式,是四色原型的MI原型的延续, 优秀服务3个特征:
  1.与领域概念相关的操作行为、但不是实体和值对象中固有的部分。
  2.接口根据领域模型中其他元素定义
  3.操作是无状态的。

  在JiveJdon3中,com.jdon.jivejdon.service.ForumService和Forum实体模型及其值对象ForumState共同完成领域模型,其中ForumService属于应用服务层;而后两者属于领域层;其他服务ForumMessageService、AccountService和UploadService等都是此类性质。

领域对象的生命周期Scope

  Spring 1.x刚出来时确实忽悠了大家一把,因为他没有领域对象的生命周期支持,直到Spring 2.0才将如new Bean scope,当初那些疯狂捧Spring 1.x 臭脚的所谓高手是不是还是基于数据库驱动的思维,根本没有真正OO模式思维,当今天JBoss Seam、Scopes等框架开始重视对象生命周期支持后,曾经发生在Jdon社区争战硝烟已经过去,成为历史。

  Eric认为:每个对象独有器生命周期,一个对象在创建以后,可能要经历各种不同的状态,并最终消亡。 对象生命周期由长短:临时对象;常驻内存;有的与其他对象存在复杂的依赖关系;状态变化时必须满足一些不变量的约束条件。 如何管理这些对象提出挑战!处理不好会偏离MDD的方向。

  在生命周期中维护对象的完整性。避免模型由于管理生命周期的复杂性而陷入困境。有 三个模式来处理:聚合(Aggregate):定义清晰的所有权和边界使模型更加紧凑,避免出现盘根错节的对象关系网;工厂(Factory)和组合(Respository)。

  当一个对象生命周期之始,使用工厂和组合提供了访问和控制模型对象的方法,完善了MDD。 建立聚合的模型,并且把工厂和组合加入设计中来,可以使我们系统地对模型对象进行管理。 聚合圈出一个范伟,在这个范围中,对象无论在哪个生命周期,保持不变性。

  在JiveJdon3.0中,值对象ForumState是被聚合在实体模型Forum中,Forum作为ForumState的一个根,由于它们数据必须保持一致性,不变量(invariant)是指无论何时发生数据变化必须满足一致性规则,由于根控制了访问,就无法绕过它修改内部元素,例如,如果没有Forum实体对象这个根,就无法去修改对象状态ForumState,ForumState获得是通过Forum的getter方法获得的。

  ForumState和Forum的分离有可以使修改论坛状态数据(当发一个新帖时,必须更新当前论坛的最新帖子为该新帖),不会影响到Forum其他元素,特别是使用事务锁定时,不必锁住整个对象,见"领域驱动设计"书籍P92。

  另外,ForumThread和ForumMessage的关联关系必设定成单向的,而不是双向的,因为领域建模中,关联越简单越好。

  在JiveJdon3.0中,你可能注意到有一个com.jdon.jivejdon.service.factory.ForumBuilder,所有实体模型对象的获得都是从这个工厂创建出来的,我曾经徘徊过:这个工厂类是否应该属于持久层,因为JiveJdon3.0持久层没有使用Hibernate这样O/R Mapping框架,而是直接使用SQL,但是从持久层输出的都是对象,这是必须坚持的一个设计原则(好像是MF的一个什么元数据模式) 。

  但是,Eric明确告诉我们,领域模型的工厂属于应用层,页就是还是应该处于业务层的,这样好处很多,业务层设计根本无需从Hibernate等持久层框架获得,而是从自己的工厂获得。

  组合(Respository)又被翻译成仓储,我认为组合合适,主要用来返回一批对象,查询组合常用来返回批量查询结果,JdonFramework两个快速开发支持:批量查询其实应该是Respository的实现,实际也是过去Master-details的一种查询实现。

  以com.jdon.jivejdon.presentation.action.ThreadListAction为例子,其功能是查询论坛Forum下所有主题ForumThread,并分页显示,实现效果按这里,我们在customizeListform方法中将根Model Forum设置进入,在threadList.jsp中,我们使用struts的标签库logic:iterator来遍历组合对象threadListform中的ForumThread集合。

失血模型

  MF(Martin Fowler)曾经提出有名的贫血模型或失血模型,让我们好生迷惑和彷徨,他认为实体模型对象中只有弱行为setter和getter方法,没有真正行为,好像缺少血液的人,不和谐了,不少高手又被忽悠了,大谈贫血模型。

  其实,Eric已经认为,在DDD中,领域中一些概念不能作为模型中的对象来处理的,如果将这些功能概念强行加给实体对象和值对象,破坏模型中对象的定义,人为添加没有意义的对象。服务是描述领域概念最自然的方式。

  为了在这些大师之间取得一个平衡,有人将Model的持久化操作(CRUD行为)整入到领域模型中,这是不是违背当初Dao模式初衷,Dao模式其实是桥模式和适配器模式组合(见SUN的J2EE核心模式)。

  无论如何,我们的DDD项目中都是以失血模型存在着,所以,Eric呼唤:建模专家必须懂得实现,懂得软件技术,MF可能会听进去的。


(以上文字源自板桥本人的第四届中国软件技术大会“领域设计建模”演讲稿 )

你可能感兴趣的:(设计模式,编程,软件测试,OO,领域模型)