PDF《在线版本 免费在线版本》

免费 免费 免费在线版本 在线版本 在线版本 (非印刷免费在线版) InfoQ InfoQ InfoQ 中文站出品 本书由 InfoQ 中文站免费发放,如果您从其他渠道获取本 书,请注册 InfoQ 中文站以支持作者和出版商, 并免费下载更多 InfoQ 企业软件开发系列图书.

本书主页为 http://infoq.com/ http://infoq.com/ http://infoq.com/cn/ cn/ cn/minibooks/domain-driven-design- minibooks/domain-driven-design- minibooks/domain-driven-design- quickly quickly quickly iii 领域驱动设计 领域驱动设计 领域驱动设计 精简版 精简版 精简版 ?

2006 C4Media Inc. 版权所有 C4Media 是InfoQ.com 这一企业软件开发社区的出版商 本书属于 InfoQ 企业软件开发系列图书 如果您打算订购 InfoQ 的图书,请联系 [email protected] 未经出版者预先的书面许可,不得以任何方式复制或者抄袭本书的任何 部分,本书任何部分不得用于再印刷,存储于柯重复使用的系统,或者 以任何方式进行电子、机械、复印和录制等形式传播. 本书提到的公司产品或者使用到的商标为产品公司所有. 如果读者要了解具体的商标和注册信息,应该联系相应的公司. 本书用到的图片在 Creative Commons License 许可下使用,并征得 Addison-Wesley 于2004 年出版的 DOMAIN DRIVEN DESIGN 一书作 者Eric Evans 的许可. 本书封面基于 Creative Commons License,并征得 Addison-Wesley 于2004 年出版的 DOMAINDRIVEN DESIGN 一书作者 Eric Evans 的许 可. 英文版责任编辑:Floyd Marinescu 英文版封面设计:Gene Steffanson 英文版美术编辑:Laura Brown 和Melissa Tessier 向Eric Evans 致以特别的谢意 中文版翻译:孙向晖 霍泰稳 中文版责任编辑:霍泰稳 中文版美术编辑:吴志民 欢迎共同参与 InfoQ 中文站的内容建设工作,包括原创投稿和翻译等, 请联系 [email protected] .

10 9

8 7

6 5

3 2

1 v 译译译序序序一一一在2004 年之前的某一天,我和所在部门的一个设计师进行沟通,当 时他为自己的一个思路兴奋不已,而我要做的事情就是跟他讨论清 楚他头脑中的那个想法,然后写出需求和设计文件来.大家可能会 注意到,很多时候,需求是从设计中反推出来的,这被一些专家称 为 需求的反向工程 .其实我更多地认为这是由于我们现在糟糕 的工作现状决定的,有诸多的因素导致需求或者设计被局限在仅有 的几个人的知识体系中,但如果有心去细察,会发现他们各自的理 解又各不相同. 回到刚才说到的那次沟通上,当那个设计师把自己的得意之作描述 完毕后,我在纸上用 UML 图画出了他的主题思路,然后我们针对细 节开始探讨并在图上改改画画.最后的修订结果显示,他的很多 创举 是多余的,经过精简后的 UML 基本上颠覆了他原有的思路.现 在我还记得那位同事的一声叹息: 一周的功夫白费了…… 其实在整件事情中,他有他的得失,我也有我的收获和困惑:我意 识到对统一的核心模型进行探讨和简化的重要性,但应该如何把这 样的过程程式化,让它在更多的同事的工作中发挥作用呢? 这样的问题纠缠了我好久,终于有一天,我得到了一本如字典般的 硬皮 Domain Driven Design(我们亲切地称它为 DDD )原版 书,从中找到了答案.然后,我参与了 DDD 中文版的审校工作和 DDD 注释版的注释工作.再后来,InfoQ 中文站的总编霍泰稳又邀 请我一起做了 Domain Driven Design Quickly 这本书的翻译工作. 曾经有人要我用简练的词汇描述 DDD 的中心思想,我个人认为这是 一个比较难的工作,但我愿意去尝试.我的回答是 关注精简的业务 模型及实现的匹配 : 1. 1. 1. 如果你了解 模型 的定义是对现实的有选择性的精简,然后用这样 的观点去读 DDD 这本书,你就会发现,DDD 其实没有什么太多的 新鲜玩意,它更多地是可以看作是面向对象思潮的回归和升华.在 一个 万事万物皆对象 的世界里,哪些对象是对我们的系统有用的? 哪些是对我们拟建系统没有用处的?我们应该如何保证我们选取的 模型对象恰好够用? 2. 2. 2. 前面的选择性问题只是解决了一个初步框选的问题,对象并不是 独立存在的,它们之间有着千丝万缕的联系.这种扯不断理还乱的 联系构成了系统的复杂性.一个具体的体现就是,我们修改了一处 变更,结果引发了一系列的连锁反应.虽然对象的封装机制可以帮 我们解决一部分问题,但那只是有限的一部分.我们应该如何在一 个更高点的层次上,通过保留对象之间有用的关系去除无用的关 系,并且限定变更影响的范围以来降低系统的复杂度呢? 3. 3. 3. 在DDD 以及传统 OO 的观点中,业务而不是技术是一个开发团 队首先要关注的内容,众多的框架和平台产品也在宣称把开发人员 解放出来,让他们有更多的精力去关注业务.但是,当我们真正去 看待时,会发现,开发人员大多还是沉溺于技术中,对业务的理解 和深入付出的太少太少.其实要解决这个问题,就要先看清楚我们 提炼出来的模型,在整个架构和整个开发过程中所处的位置和地位. 我们经常听到两个词,一个是 MDD(模型驱动设计),一个是 MDA(模型驱动架构).如果 DDD 特别关注的是 M (以及其实 现),那么,这个 M 应该如何与架构和开发过程相融合呢?我经常会 看到我们辛苦提取出来的领域模型被肢解后,分散到系统的若干角 落.这真是一件可怕的事情,因为一旦形成了 人脑拼图 ,就很难再 有一个人将它们一一复原,除非这个人是个天才. 4. 4. 4. 很多面向对象的教材,都会告诉你若干的技巧,让你去机械化地 处理模型和对象实现,但是这些教材通常会忽略一个大的上下文环 境,就是应该由哪些具有什么样素质和技能的人来处理模型和对象 实现,或者说白了,就是应该用什么样的团队模型来匹配业务模型. 不同的模型,需要不同的团队模型的支撑,不同的团队模型也会让 一个模型实现更优秀或者更糟糕. 5. 5. 5. 相信很多人读过 ATM 机的例子,你发现自己彻底明白了用例应该 怎么编写、模型怎么提取和实现,但是当你信心十足地去开始你自 己的项目时,你又会发现你的思路片段化了,所有你明白了的技能 在你的新项目中好像用不上.算了,还是老的工作思路和工作方式 比较顺手,于是一切都照旧会到了老的套路上.那么,面向对象技 术或者说我们提炼出来的模型应该如何在大型项目/团队中使用呢? 我们是应该要求一个项目使用统一的模型,还是应该把它们分成不 同的模型?我们应该如何抉择? …… vii 在实际的应用过程中,我相信每一个有心人都会提出比我在这里列 举出来的还要多的问题,没有关系,DDD 这本书都能给你所需的答 案. 当然, DDD 作为传统 OO 范型的探索和升华版,也存在着一些 不足和未涉及的领域,例如:在安全、权限方面的考虑,其基本构 造块的适用范围和决策标准,与开发框架之间更好的融合性等问 题.还好,我们都知道 尽信书不如无书 的道理,在阅读任何著作 时,都应该带着自己的疑惑和批判精神去阅读,你的任何关于 DDD 的深层思考和讨论,都可以在它的配套网站或者 InfoQ 中文站网站 中发表. 如果你认为阅读 DDD 这么一本如字典版的大厚书时间上不太允许, 那么请允许我为你介绍一本简化版的小书 Domain Driven Design Quickly,经过我们的努力,InfoQ 中文站已经将其翻译成中文版― ―《领域驱动设计精简版》,并作为国庆礼物奉献给大家! 那还等什么呢,祝你开卷有益,阅读愉快! 孙向晖 孙向晖 孙向晖