领域驱动设计--软件核心复杂性应对之道
点击看大图基本信息
- 作者： （美）Eric Evans [作译者介绍]
- 译者： 陈大峰 张泽鑫 等
- 出版社：清华大学出版社
- ISBN：7302115761
- 上架时间：2006-3-16
- 出版日期：2006 年3月
- 开本：185×260
- 页码：390
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
内容简介回到顶部↑
[font color="#ff6600"]“每个有思想的软件开发者的书架上都应该有这样一本书”——kent beck
“eric设法收集了经验丰富的对象设计人员一直使用的一些设计过程，作为一个团队的人们在这些过程中却没能够成功地完成剩下的工作。人们将知识弄得支离破碎……却从来没有将建立领域逻辑的原则组织起来并使其系统化。这本书是非常重要的。”—— kyle brown，《enterprise java programming with ibm websphere》的作者。[/font]
本书涉及的主题具体包括：
●隔离领域●实体、值对象、服务和模块●一个领域对象的生命周期●将过程表示为领域对象●创建没有副作用的函数●总体轮廓●独立的类●扩展说明●应用分析模式●将设计模式与模型相联系●维护模型的完整性●设计领域前景声明●选择重构目标●职责层次●创建可插入的组件框架●结合大比例结构与界限上下文
本书为读者系统地介绍了领域驱动的设计方法。书中介绍了大量优秀的设计示例、基于经验的技术以及促进处理复杂领域的软件开发的基本原则。本书将设计和开发实践相结合，在介绍领域驱动设计时，还提供了大量的java示例，这些例子都是从实际中提取出来的，展示了领域驱动设计在软件开发中的实际应用。 通过对本书的阅读，读者将获得对领域驱动设计的总体认识，了解领域驱动设计中涉及的关键原则、术语和推断。本书介绍的经验和标准模式将为开发团队提供一种通用语言。另外，书中还介绍了如何在领域模型中进行重构，如何与敏捷开发进行集成，如何获得对领域更深的认识并增进领域专家和程序员之间的交流等。并在此基础上，介绍了在复杂系统和较大组织中进行的领域驱动设计。
“eric设法收集了经验丰富的对象设计人员一直使用的一些设计过程，作为一个团队的人们在这些过程中却没能够成功地完成剩下的工作。人们将知识弄得支离破碎……却从来没有将建立领域逻辑的原则组织起来并使其系统化。这本书是非常重要的。”—— kyle brown，《enterprise java programming with ibm websphere》的作者。[/font]
本书涉及的主题具体包括：
●隔离领域●实体、值对象、服务和模块●一个领域对象的生命周期●将过程表示为领域对象●创建没有副作用的函数●总体轮廓●独立的类●扩展说明●应用分析模式●将设计模式与模型相联系●维护模型的完整性●设计领域前景声明●选择重构目标●职责层次●创建可插入的组件框架●结合大比例结构与界限上下文
本书为读者系统地介绍了领域驱动的设计方法。书中介绍了大量优秀的设计示例、基于经验的技术以及促进处理复杂领域的软件开发的基本原则。本书将设计和开发实践相结合，在介绍领域驱动设计时，还提供了大量的java示例，这些例子都是从实际中提取出来的，展示了领域驱动设计在软件开发中的实际应用。 通过对本书的阅读，读者将获得对领域驱动设计的总体认识，了解领域驱动设计中涉及的关键原则、术语和推断。本书介绍的经验和标准模式将为开发团队提供一种通用语言。另外，书中还介绍了如何在领域模型中进行重构，如何与敏捷开发进行集成，如何获得对领域更深的认识并增进领域专家和程序员之间的交流等。并在此基础上，介绍了在复杂系统和较大组织中进行的领域驱动设计。
作译者回到顶部↑
本书提供作译者介绍
陈大峰，国防科技大学计算机科学与技术博士，研究方向：分布式计算：研究课题为过程集成工作流。对UML建模、EDOC、工作流和过程集成有深入的研究， 曾发表多篇论文和专业文章。 目前担任某消息代理中间件产品开发组长，—直使用UML作为设计工具和沟通工具，并取得显著成果。...
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第ⅰ部分 让领域模型发挥作用.
第1章 消化知识 5
1.1 有效建模的因素 9
1.2 知识消化 10
1.3 持续学习 11
1.4 知识丰富的设计 12
1.5 深层模型 15
第2章 交流及语言的使用 17
2.1 通用语言 17
2.2 利用对话改进模型 22
2.3 一个团队，一种语言 24
2.4 文档和图 25
2.4.1 书面的设计文档 27
2.4.2 执行的基础 29
2.5 说明性模型 29
第3章 将模型和实现绑定 32
3.1 模型驱动设计 33
3.2 建模范型和工具支持 36
3.3 突出主旨：为什么模型对用户很关键 41
3.4 实践型建模人员 43
第1章 消化知识 5
1.1 有效建模的因素 9
1.2 知识消化 10
1.3 持续学习 11
1.4 知识丰富的设计 12
1.5 深层模型 15
第2章 交流及语言的使用 17
2.1 通用语言 17
2.2 利用对话改进模型 22
2.3 一个团队，一种语言 24
2.4 文档和图 25
2.4.1 书面的设计文档 27
2.4.2 执行的基础 29
2.5 说明性模型 29
第3章 将模型和实现绑定 32
3.1 模型驱动设计 33
3.2 建模范型和工具支持 36
3.3 突出主旨：为什么模型对用户很关键 41
3.4 实践型建模人员 43
译者序回到顶部↑
在项目中担任过分析和设计工作的人，对于下面一些问题，一定会与译者一样深有同感：.
概念混淆，术语混乱—— 在讨论时，经常发现不同的人把同一个词理解为不同的概念，导致沟通无法顺利进行；
设计似乎很难理解—— 开发人员无法很快抓住设计的重点，甚至会出现不同程度和方向的曲解；
代码也很难理解—— 阅读代码比编写代码更痛苦，即使它严格地遵循了缩进规则和命名规范；
当需求发生变化时，发现要对设计作大量修改——框架、模式似乎并未带来所需的灵活性；
当系统的复杂性达到相当程度时，整个项目似乎会无可避免地滑入“焦油坑”，或者为维护工作而疲于奔命。
如果您想思考为什么会出现这些问题，以及如何解决它们的话，请您深入地阅读本书。在阅读本书的过程中，您一定能够体会到一种豁然开朗的惊喜、一种跃跃欲试的冲动。
一旦您试着把书中的理念付诸实践，您就会发现，这些问题其实并不是不可捉摸的——您会觉得自己洞若观火，然后把它们手到擒来——这种经历曾经让译者欣喜若狂。例如，维护并严格遵循“通用语言”来处理第1个问题；对模型进行“精炼”、采用“大比例结构”等来解决第2个问题；“释意接口”、“声明性设计”等解决第3个问题，等等。..
“领域驱动设计”认为，对于大多数软件项目而言，其根本着眼点应该集中于领域和领域逻辑；而复杂的领域设计应该是基于模型的。许多系统的真正复杂之处不在于技术，而在于领域本身，在于业务用户及其执行的业务活动。如果在设计时没有获得对领域的深刻理解，没有通过模型将复杂的领域逻辑以模型概念和模型元素的形式清晰地表达出来，那么无论我们使用多么先进、多么流行的平台和设施，都难以保证项目的真正成功。
领域驱动设计能有效地加快软件项目的开发速度，并大大提高我们所能解决的问题的复杂度。它指导我们从混乱和复杂的领域中找出秩序和规律，抽象出一套通用语言，并通过恰当地运用一系列模式和策略来发挥通用语言的巨大作用。这是一个相当需要技巧和经验的过程。能够真正深入地理解、掌握和运用这些技巧和经验就已非常不易，而将这些技巧和经验总结和整理出来就显得尤为珍贵。
阅读本书将是学习这些技巧和经验的非常直接、快速、事半功倍的途径——这是我们在翻译过程中的深切感受。本书不仅为我们描述了领域驱动设计所需的技巧和经验，而且把它们组织整理成为了一种系统、清晰的知识体系，使我们能够循序渐进地学习和掌握领域驱动设计的精要所在。同时，丰富的、生动具体的实例使我们能够更轻松地领会领域驱动设计的各种原则和策略。读者一定能从本书中获取有用的知识和思想、掌握和运用领域驱动设计，并领导软件项目走向成功。
本书的翻译工作由陈大峰、张泽鑫等人共同完成，并由UMLChina的孙向晖、潘加宇负责技术审校。在此，译者对二位所做的工作表示衷心的感谢。
本书的翻译、编辑和审校工作前后历时两年多，可谓精心打造，希望其出版质量能够让广大读者满意。但由于我们水平有限，可能仍会有偏差甚至错误之处存在，恳请读者批评指正。信息反馈邮箱：fwhbook@tup.tsinghua.edu.cn。...
译 者
2004年12月
概念混淆，术语混乱—— 在讨论时，经常发现不同的人把同一个词理解为不同的概念，导致沟通无法顺利进行；
设计似乎很难理解—— 开发人员无法很快抓住设计的重点，甚至会出现不同程度和方向的曲解；
代码也很难理解—— 阅读代码比编写代码更痛苦，即使它严格地遵循了缩进规则和命名规范；
当需求发生变化时，发现要对设计作大量修改——框架、模式似乎并未带来所需的灵活性；
当系统的复杂性达到相当程度时，整个项目似乎会无可避免地滑入“焦油坑”，或者为维护工作而疲于奔命。
如果您想思考为什么会出现这些问题，以及如何解决它们的话，请您深入地阅读本书。在阅读本书的过程中，您一定能够体会到一种豁然开朗的惊喜、一种跃跃欲试的冲动。
一旦您试着把书中的理念付诸实践，您就会发现，这些问题其实并不是不可捉摸的——您会觉得自己洞若观火，然后把它们手到擒来——这种经历曾经让译者欣喜若狂。例如，维护并严格遵循“通用语言”来处理第1个问题；对模型进行“精炼”、采用“大比例结构”等来解决第2个问题；“释意接口”、“声明性设计”等解决第3个问题，等等。..
“领域驱动设计”认为，对于大多数软件项目而言，其根本着眼点应该集中于领域和领域逻辑；而复杂的领域设计应该是基于模型的。许多系统的真正复杂之处不在于技术，而在于领域本身，在于业务用户及其执行的业务活动。如果在设计时没有获得对领域的深刻理解，没有通过模型将复杂的领域逻辑以模型概念和模型元素的形式清晰地表达出来，那么无论我们使用多么先进、多么流行的平台和设施，都难以保证项目的真正成功。
领域驱动设计能有效地加快软件项目的开发速度，并大大提高我们所能解决的问题的复杂度。它指导我们从混乱和复杂的领域中找出秩序和规律，抽象出一套通用语言，并通过恰当地运用一系列模式和策略来发挥通用语言的巨大作用。这是一个相当需要技巧和经验的过程。能够真正深入地理解、掌握和运用这些技巧和经验就已非常不易，而将这些技巧和经验总结和整理出来就显得尤为珍贵。
阅读本书将是学习这些技巧和经验的非常直接、快速、事半功倍的途径——这是我们在翻译过程中的深切感受。本书不仅为我们描述了领域驱动设计所需的技巧和经验，而且把它们组织整理成为了一种系统、清晰的知识体系，使我们能够循序渐进地学习和掌握领域驱动设计的精要所在。同时，丰富的、生动具体的实例使我们能够更轻松地领会领域驱动设计的各种原则和策略。读者一定能从本书中获取有用的知识和思想、掌握和运用领域驱动设计，并领导软件项目走向成功。
本书的翻译工作由陈大峰、张泽鑫等人共同完成，并由UMLChina的孙向晖、潘加宇负责技术审校。在此，译者对二位所做的工作表示衷心的感谢。
本书的翻译、编辑和审校工作前后历时两年多，可谓精心打造，希望其出版质量能够让广大读者满意。但由于我们水平有限，可能仍会有偏差甚至错误之处存在，恳请读者批评指正。信息反馈邮箱：fwhbook@tup.tsinghua.edu.cn。...
译 者
2004年12月
前言回到顶部↑
从领先的软件设计人员开始将领域建模及设计视为关键性课题到现在至少已经有20年的时间了，然而令人惊讶的是，几乎没有相关的文献来告诉大家应该做什么和如何做。尽管领域建模和设计并没有被明确地形式化，然面在对象领域中出现了一种潜在的哲学体系，它就是我所说的领域驱动设计(domain-driven design)。.
我花费10年时间开发了几个商业和技术领域的复杂系统。在工作过程中，我尝试了几种已经出现在面向对象开发前沿领域的设计与开发程序。这些项目中有一些非常成功，也有少数几个最终失败。成功项目的共同特征是在迭代的设计中不断地完善领域模型并将它作为项目的骨干结构的一部分。
本书提供了进行设计决策的框架和讨论领域设计时使用的技术，集中了被广泛接受的优秀实践，这些案例都是在我自己的领域与工作中的经验积累。需要面对复杂领域的软件开发团队可以使用这个框架来系统地进行领域驱动设计。
比较3个项目
在我的记忆中，有3个项目能够作为说明动态领域建模设计如何影响开发结果的生动示例。尽管这3个项目都交付了实用的软件，然而只有一个达到了优秀的目标，并且生成了能够根据组织不断发展的要求进行持续完善的复杂软件。
我注意到一个非常迅速地提交了简单实用的基于Web的贸易系统的项目。开发人员们任凭自己的感觉进行开发，但这种态度并没有对他们的工作造成阻碍，因为一个简单软件的编写并不需要注意设计问题。初始成功的结果是，对于未来继续开发的要求极高。这时我被要求进入第2版本的开发工作。仔细地研究了这个项目后，我发现他们缺少一个领域模型，甚至连项目通用的语言都没有，整个设计处于无结构状态。项目的领导者不同意我的论断，于是我拒绝了这个工作。一年后，这个开发团队陷入困境，无法交付第2个版本。尽管他们对技术的使用方式并无什么错误，从业务逻辑来看，我们还是应该克服这种情况。他们的第1个版本过早地固化导致了高额的维护代价。
处理这种高度复杂的问题要求对领域逻辑的设计采用更加认真的方法。在我事业的早期，非常幸运地能够完成一项格外重视领域设计的项目。该项目的复杂性不小于前面提到的第一个任务，也同样是一开始向贸易商提交了一个简单的应用软件，适度地完成初始工作。但是这次情况有所不同，初始交付的版本不断地加速开发。每一次迭代都会对前一个版本功能的整合与细化提出令人兴奋的新意见。开发团队能够灵活地进行扩展以反馈贸易商的要求。这种向上的良好发展轨迹直接归功于一个明确的领域模型，迭代地改进并快速地编码。随着团队对领域更进一步的洞察，模型也随之进一步深化。开发人员之间甚至开发人员与领域专家之间的交流得以改善，项目的设计也不像以前那样带来艰巨的维护任务，而变得易于修改和扩展了。
遗憾的是，项目并不会仅仅因为认真进行建模而进入一个良性循环。我过去接触过一个项目，开始时基于领域模型是要建立一个全球企业系统，但是经过几年屡屡受挫，不得不降低目标而落入俗套。这个团队有良好的工具与对业务的深入理解，并且对于建模也格外重视。然而拙劣的开发角色划分使得模型与实现相互分离，因此设计并没有反映出分析的深度。在任何情况下，详细的业务对象设计并不是保证它们在复杂精细项目中完美结合的充分条件。再三的迭代并不能够提高编码质量，因为开发人员之间技术水平不均衡，而他们又不了解面向实际的运行软件而建立基于模型的对象的技术与其本身的风格。时间一点点过去，开发工作陷入复杂的泥潭，团队也丧失了对系统的整体把握。经过几年的工作，该项目并没有生产出有用的软件，该团队却不得不放弃其初始时建模的目标。
复杂度的难题
很多原因会导致一个项目偏离正确轨道：官僚主义、不明确的目标、资源的匮乏以及其他诸多因素。但是设计能够在很大程度上决定软件的复杂度。当复杂度变得难以控制时，开发人员便不再能够很好地理解软件，从而也不能够方便和安全地对它进行改变与扩展。另一方面，一个优秀的设计会为开发这些复杂特性带来机会。
一些设计因素是技术上的，在网络、数据库和其他软件技术方面的设计已经有了很多研究，这些问题的解决方法也有许多书籍专门论述。开发人员们不断提升自己的技能并紧跟着每一次的技术进步。
然而许多应用程序最大的复杂性不在技术方面，而是在领域本身，用户的活动或业务方面。如果在设计中没有处理好领域复杂性，那么基础设施技术再好也不管用。一个成功的设计必须系统地处理软件的这个核心方面。
本书的前提有两个：
对于多数软件项目，主要的焦点应该在领域及领域逻辑方面。..
复杂的领域设计应该基于一个模型来进行。
领域驱动的设计既是一种思考的方式也是一系列的要优先考虑的事情，目的在于加速处理复杂领域的软件项目。为了达到这个目标，本书提供了大量的设计实践、技巧和原则。
设计与开发过程
设计方面的书籍与过程方面的书籍很少相互提及，其中每个主题本身就是一个很复杂的问题。本书是一本关于设计方面的著作，但是我认为设计与过程是不可分割的。设计理念必须得以成功实现，否则它们将仅仅止步于学术讨论。
在人们学习设计技术时，常常会为各种可能性感到兴奋不已。接着他们会遇到实际项目的杂乱现状，他们无法将新的设计思路应用在必须使用的技术上。或者是他们不知道何时应该抛开设计方面的局限，何时又应该严格地遵循设计，寻找一个正确的解决方案。开发人员们相互讨论抽象的应用程序设计原则，但更为实际的是讨论现实的项目如何完成。因此，尽管这是一本设计书籍，在需要时我仍然会涉及到过程领域的知识。这样做更有助于在合适的上下文中讨论设计原则。
本书并不局限于某一特定的方法学，然而它是面向新的“敏捷开发过程”系列的。它假设项目实践中有几个约定俗成的惯例。下面两个惯例是本书所采用方法的先决条件。
我花费10年时间开发了几个商业和技术领域的复杂系统。在工作过程中，我尝试了几种已经出现在面向对象开发前沿领域的设计与开发程序。这些项目中有一些非常成功，也有少数几个最终失败。成功项目的共同特征是在迭代的设计中不断地完善领域模型并将它作为项目的骨干结构的一部分。
本书提供了进行设计决策的框架和讨论领域设计时使用的技术，集中了被广泛接受的优秀实践，这些案例都是在我自己的领域与工作中的经验积累。需要面对复杂领域的软件开发团队可以使用这个框架来系统地进行领域驱动设计。
比较3个项目
在我的记忆中，有3个项目能够作为说明动态领域建模设计如何影响开发结果的生动示例。尽管这3个项目都交付了实用的软件，然而只有一个达到了优秀的目标，并且生成了能够根据组织不断发展的要求进行持续完善的复杂软件。
我注意到一个非常迅速地提交了简单实用的基于Web的贸易系统的项目。开发人员们任凭自己的感觉进行开发，但这种态度并没有对他们的工作造成阻碍，因为一个简单软件的编写并不需要注意设计问题。初始成功的结果是，对于未来继续开发的要求极高。这时我被要求进入第2版本的开发工作。仔细地研究了这个项目后，我发现他们缺少一个领域模型，甚至连项目通用的语言都没有，整个设计处于无结构状态。项目的领导者不同意我的论断，于是我拒绝了这个工作。一年后，这个开发团队陷入困境，无法交付第2个版本。尽管他们对技术的使用方式并无什么错误，从业务逻辑来看，我们还是应该克服这种情况。他们的第1个版本过早地固化导致了高额的维护代价。
处理这种高度复杂的问题要求对领域逻辑的设计采用更加认真的方法。在我事业的早期，非常幸运地能够完成一项格外重视领域设计的项目。该项目的复杂性不小于前面提到的第一个任务，也同样是一开始向贸易商提交了一个简单的应用软件，适度地完成初始工作。但是这次情况有所不同，初始交付的版本不断地加速开发。每一次迭代都会对前一个版本功能的整合与细化提出令人兴奋的新意见。开发团队能够灵活地进行扩展以反馈贸易商的要求。这种向上的良好发展轨迹直接归功于一个明确的领域模型，迭代地改进并快速地编码。随着团队对领域更进一步的洞察，模型也随之进一步深化。开发人员之间甚至开发人员与领域专家之间的交流得以改善，项目的设计也不像以前那样带来艰巨的维护任务，而变得易于修改和扩展了。
遗憾的是，项目并不会仅仅因为认真进行建模而进入一个良性循环。我过去接触过一个项目，开始时基于领域模型是要建立一个全球企业系统，但是经过几年屡屡受挫，不得不降低目标而落入俗套。这个团队有良好的工具与对业务的深入理解，并且对于建模也格外重视。然而拙劣的开发角色划分使得模型与实现相互分离，因此设计并没有反映出分析的深度。在任何情况下，详细的业务对象设计并不是保证它们在复杂精细项目中完美结合的充分条件。再三的迭代并不能够提高编码质量，因为开发人员之间技术水平不均衡，而他们又不了解面向实际的运行软件而建立基于模型的对象的技术与其本身的风格。时间一点点过去，开发工作陷入复杂的泥潭，团队也丧失了对系统的整体把握。经过几年的工作，该项目并没有生产出有用的软件，该团队却不得不放弃其初始时建模的目标。
复杂度的难题
很多原因会导致一个项目偏离正确轨道：官僚主义、不明确的目标、资源的匮乏以及其他诸多因素。但是设计能够在很大程度上决定软件的复杂度。当复杂度变得难以控制时，开发人员便不再能够很好地理解软件，从而也不能够方便和安全地对它进行改变与扩展。另一方面，一个优秀的设计会为开发这些复杂特性带来机会。
一些设计因素是技术上的，在网络、数据库和其他软件技术方面的设计已经有了很多研究，这些问题的解决方法也有许多书籍专门论述。开发人员们不断提升自己的技能并紧跟着每一次的技术进步。
然而许多应用程序最大的复杂性不在技术方面，而是在领域本身，用户的活动或业务方面。如果在设计中没有处理好领域复杂性，那么基础设施技术再好也不管用。一个成功的设计必须系统地处理软件的这个核心方面。
本书的前提有两个：
对于多数软件项目，主要的焦点应该在领域及领域逻辑方面。..
复杂的领域设计应该基于一个模型来进行。
领域驱动的设计既是一种思考的方式也是一系列的要优先考虑的事情，目的在于加速处理复杂领域的软件项目。为了达到这个目标，本书提供了大量的设计实践、技巧和原则。
设计与开发过程
设计方面的书籍与过程方面的书籍很少相互提及，其中每个主题本身就是一个很复杂的问题。本书是一本关于设计方面的著作，但是我认为设计与过程是不可分割的。设计理念必须得以成功实现，否则它们将仅仅止步于学术讨论。
在人们学习设计技术时，常常会为各种可能性感到兴奋不已。接着他们会遇到实际项目的杂乱现状，他们无法将新的设计思路应用在必须使用的技术上。或者是他们不知道何时应该抛开设计方面的局限，何时又应该严格地遵循设计，寻找一个正确的解决方案。开发人员们相互讨论抽象的应用程序设计原则，但更为实际的是讨论现实的项目如何完成。因此，尽管这是一本设计书籍，在需要时我仍然会涉及到过程领域的知识。这样做更有助于在合适的上下文中讨论设计原则。
本书并不局限于某一特定的方法学，然而它是面向新的“敏捷开发过程”系列的。它假设项目实践中有几个约定俗成的惯例。下面两个惯例是本书所采用方法的先决条件。
)
加载中...