领域驱动设计DDD之读书笔记

查看文章

领域驱动设计DDD之读书笔记  转载原地址：http://hi.baidu.com/lijiangzj

2007-08-17 16:53

一、当前Java软件开发中几种认识误区

Hibernate是一个基于对象模型持久化的技术，因此，关键是我们需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分 层等有效办法处理关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂（没有科学方法处理、侦察或减少这些关系），必然导致 系统运行缓慢，其实同样问题也适用于当初对EJB的实体Bean的CMP抱怨上，实体Bean是Domain Model持久化，如果不首先设计Domain Model，而是设计数据表，和持久化工具设计目标背道而驰，能不出问题吗？关于这个问题N多年就在Jdon争论过。

　　这里同样延伸出另外一个问题：数据库设计问题，数据库是否需要在项目开始设计？
如果我们进行数据库设计，那么就产生了一系列问题：当我们使用Hibernate实现持久保存时，必须考虑事先设计好的数据库表结构以及他们的关系如何和 业务对象实现映射，这实际上是非常难实现的，这也是很多人觉得使用ORM框架棘手根本原因所在。

　　当然，也有脑力相当发达的人可以 实现，但是这种围绕数据库实现映射的结果必然扭曲业务对象，这类似于两个板块（数据表和业务对象）相撞，必然产生地震，地震的结果是两败俱伤， 软的一方吃亏，业务对象是代码，相对于不容易变更的数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO, DTO满天飞，性能和维护问题随之而来。

      现在回到我们讨论的重点上来，分层架构是我们使用Java的根本原因之一，域建模专家Eric Evans在他的“Domain Model Design”一书中开篇首先强调的是分层架构，整个DDD理论实际是告诉我们如何使用模型对象oo技术和分层架构来设计实现一个Java项目。

二、面向对象与领域建模

需求分析方法演变
历史上，对需求分析方法可以说经过三个阶段：

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

第二阶段：面向对象的分析设计方法诞生后，有了专门的分析和设计阶段之分，我们使用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发展可以看到一个侧面：工业厂商更多关心的是功能，而不是设计？


分层架构

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

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

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

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

建模与项目管理

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

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

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

三、领域模型驱动设计(Evans DDD)之模型提炼

　　如果你没有恰当的OO设计思想，Java就会用性能惩罚你，这可能是Java世界的一个潜规则。

　　那么，一个正确的OOA/OOD/OOP步骤是什么呢？目前围绕模型驱动设计(MDD)的设计思想成为主流思想，MDA更是在MDD基础上提升和升华。下面让我们首先了解，如何使用领域驱动设计思想来分析设计一个软件系统。

　　当我们不再对一个新系统进行数据库提炼时，取而代之的时面向对象的模型提炼。我们必须大刀阔斧地对业务领域进行细分，将一个复杂的业务领域划分为多个小的子领域，同时还必须分清重点和次要部分，抓住核心领域概念，实现重点突破。

核心领域模型

　　精简模型，找出核心领域，将业务需求中最有价值的概念体现出来，让核心变精要，这实际就是一个使复杂问题变简单的过程，也是对我们软件设计人员真正能力的考验。

　　核心领域模型不是轻易能够发现，特别是他处于一个纷乱复杂的众多领域模型结构中时，核心模型通常是我们某个子领域关注的重点，例如订单模型是订单管理领域的核心；消息模型是论坛或消息领域系统的核心。

　 　目前，分析领域有很多模式来帮助我们来提炼核心模型，例如四色原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的记帐模型就是不仅仅用来记录账目数值，而且可以记录和控制账目的每一次修改。而四色原型则是一种高于分析模式的一种原型基本模式， 下面是本人根据四色原型提炼的核心领域模型概念。

附、实战DDD