领域驱动设计:软件核心复杂性应对之道(深度剖析构建高质量复杂系统的核心技术)
点击看大图基本信息
- 原书名： Domain-Driven Design: Tackling Complexity in the Heart of Software
- 原出版社： Addison-Wesley Professional
- 作者： (美)Eric Evans [作译者介绍]
- 译者： 赵俐 盛海艳 刘霞
- 丛书名： 图灵程序设计丛书 软件工程系列
- 出版社：人民邮电出版社
- ISBN：9787115238870
- 上架时间：2010-11-11
- 出版日期：2010 年11月
- 开本：16开
- 页码：369
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 综合
编辑推荐
众多世界级软件大师鼎力推荐
凝聚领域建模专家数十年的实战经验
深度剖析构建高质量复杂系统的核心技术
推荐阅读
内容简介回到顶部↑
本书是领域驱动设计方面的经典之作。全书围绕着设计和开发实践，结合若干真实的项目案例，向读者阐述如何在真实的软件开发中应用领域驱动设计。书中给出了领域驱动设计的系统化方法，并将人们普遍接受的一些最佳实践综合到一起，融入了作者的见解和经验，展现了一些可扩展的设计最佳实践、已验证过的技术以及便于应对复杂领域的软件项目开发的基本原则。
本书适合各层次的面向对象软件开发人员、系统分析员阅读。
本书适合各层次的面向对象软件开发人员、系统分析员阅读。
作译者回到顶部↑
本书提供作译者介绍
Eric Evans世界著名软件建模专家，创建了Domain Language公司，致力于帮助公司机构创建与业务紧密相关的软件。他在全球各地宣讲领域驱动设计的思想，开设课程、参加会议、接受专访，拥有大批的追随者。从20世纪80年代开始，他就以设计师和程序员的双重身份参与过许多大型面向对象系统的设计和开发，涉及各种复杂的业务和技术领域。同时，他还培训和指导过许多开发团队开展极限编程实践。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第一部分 让领域模型发挥作用
第1章 消化知识
1.1 有效建模的要素
1.2 知识消化
1.3 持续学习
1.4 知识丰富的设计
1.5 深层模型
第2章 语言的交流和使用
2.1 模式：ubiquitous language
2.2 “大声地”建模
2.3 一个团队，一种语言
2.4 文档和图
2.4.1 书面设计文档
2.4.2 完全依赖可执行代码的情况
2.5 解释性模型
第3章 绑定模型和实现
3.1 模式：model-driven design
3.2 建模范式和工具支持
3.3 揭示主旨：为什么模型对用户至关重要
3.4 模式：hands-on modeler
第1章 消化知识
1.1 有效建模的要素
1.2 知识消化
1.3 持续学习
1.4 知识丰富的设计
1.5 深层模型
第2章 语言的交流和使用
2.1 模式：ubiquitous language
2.2 “大声地”建模
2.3 一个团队，一种语言
2.4 文档和图
2.4.1 书面设计文档
2.4.2 完全依赖可执行代码的情况
2.5 解释性模型
第3章 绑定模型和实现
3.1 模式：model-driven design
3.2 建模范式和工具支持
3.3 揭示主旨：为什么模型对用户至关重要
3.4 模式：hands-on modeler
译者序回到顶部↑
我最早听说Eric Evans的《领域驱动设计》是在2007年，那时我所在的项目组出于知识储备的考虑购进了一批软件设计书和相关资料。其中一篇英文的短篇技术文档与我们当时的项目非常相关，于是我们就仔细研读了一番。这篇仅有几万字的文档多次提到了Eric Evans的《领域驱动设计》，并引用了他的很多精辟观点。由于当时领域驱动设计远远没有现在这样普及，因此这些观点使我耳目一新，也给我留下了深刻的印象。随后我又经常在一些文献中看到Eric Evans的名字，更多地了解了他的领域驱动设计思想，没想到时隔几年后竟然有机会把这位大师的作品翻译出来奉献给各位读者，也算是机缘巧合了。
相信大家对这本书都不陌生，它已经成为软件设计书中的经典。在网上搜索一下，读者对它好评如潮，我再多说一句赞美的话都是多余的。而我能想到的也唯有“经典”二字，它堪称经典中的经典。
我们对“领域”这个概念都很熟悉，但有多少人真正重视过它呢？软件开发人员几乎总是专注于技术，把技术作为自己能力的展示和成功的度量。而直到Eric Evans出版了他的这部巨著之后，人们才真正开始关注领域，关注核心领域，关注领域驱动的设计，关注模型驱动的开发。相信在读完本书后，你会对软件设计有全新的认识。
我曾经和一些好友探讨过以下一些问题。项目怎样开发才能确保成功？什么样的软件才能为用户提供真正的价值？什么样的团队才算是优秀的团队？现在，在仔细研读完本书后，这些问题都找到了答案。
本书广泛适用于各种领域的软件开发项目。在每个项目的生命周期中，都会有一些重大关头或转折点。如何制定决策，如何把握项目的方向，如何处理和面对各种机会和挑战，将对项目产生决定性的影响。让我们一起跟随大师的脚步，分享他通过大量项目获得的真知灼见和开发心得吧。
最后，衷心感谢人民邮电出版社图灵公司各位编辑在翻译工作中给予的帮助和宝贵意见，感谢热心读者魏海枫，他在百忙之中抽出时间对本书译稿做了修订工作，发现并修正了很多问题。由于译者水平有限，在翻译过程中难免还会留有一些错误，恳请读者批评指正。
相信大家对这本书都不陌生，它已经成为软件设计书中的经典。在网上搜索一下，读者对它好评如潮，我再多说一句赞美的话都是多余的。而我能想到的也唯有“经典”二字，它堪称经典中的经典。
我们对“领域”这个概念都很熟悉，但有多少人真正重视过它呢？软件开发人员几乎总是专注于技术，把技术作为自己能力的展示和成功的度量。而直到Eric Evans出版了他的这部巨著之后，人们才真正开始关注领域，关注核心领域，关注领域驱动的设计，关注模型驱动的开发。相信在读完本书后，你会对软件设计有全新的认识。
我曾经和一些好友探讨过以下一些问题。项目怎样开发才能确保成功？什么样的软件才能为用户提供真正的价值？什么样的团队才算是优秀的团队？现在，在仔细研读完本书后，这些问题都找到了答案。
本书广泛适用于各种领域的软件开发项目。在每个项目的生命周期中，都会有一些重大关头或转折点。如何制定决策，如何把握项目的方向，如何处理和面对各种机会和挑战，将对项目产生决定性的影响。让我们一起跟随大师的脚步，分享他通过大量项目获得的真知灼见和开发心得吧。
最后，衷心感谢人民邮电出版社图灵公司各位编辑在翻译工作中给予的帮助和宝贵意见，感谢热心读者魏海枫，他在百忙之中抽出时间对本书译稿做了修订工作，发现并修正了很多问题。由于译者水平有限，在翻译过程中难免还会留有一些错误，恳请读者批评指正。
前言回到顶部↑
至少20年前，一些顶尖的软件设计人员就已经认识到领域建模和设计的重要性，但令人惊讶的是，这么长时间以来几乎没有人写出点儿什么，告诉大家应该做哪些工作或如何去做。尽管这些工作还没有被清楚地表述出来，但一种新的思潮已经形成，它像一股暗流一样在对象社区中涌动，我把这种思潮称为领域驱动设计（domain-driven design）。
过去10年中，我在几个业务和技术领域开发了一些复杂的系统。我在设计和开发过程中尝试了一些最佳实践，它们都是面向对象开发高手用过的领先技术。有些项目非常成功，但有几个项目却失败了。成功的项目有一个共同的特征，那就是都有一个丰富的领域模型，这个模型在迭代设计的过程中不断演变，而且成为项目不可分割的一部分。
本书为作出设计决策提供了一个框架，并且为讨论领域设计提供了一个技术词汇库。本书将人们普遍接受的一些最佳实践综合到一起，并融入了我自己的见解和经验。面对复杂领域的软件开发团队可以利用这个框架来系统性地应用领域驱动的设计。
三个项目的对比
谈到领域设计实践对开发结果的巨大影响时，我的记忆中立即就会跳出三个项目，它们就是鲜活的例子。虽然这三个项目都交付了有用的软件，但只有一个项目实现了宏伟的目标——交付了能够满足组织后续需求、可以不断演进的复杂软件。
我要说的第一个项目完成得很迅速，它提供了一个简单实用的Web交易系统。开发人员主要凭直觉开发，但这并没有妨碍他们，因为简单软件的编写并不需要过多地注意设计。由于最初的这次成功，人们对未来开发的期望值变得极高。我就是在这个时候被邀请开发它的第二个版本的。当我仔细研究这个项目时，发现他们没有使用领域模型，甚至在项目中没有一种公共语言，而且项目完全没有一种结构化的设计。项目领导者对我的评价并不赞同，于是我拒绝了这项工作。一年后，这个项目团队陷入困境，无法交付第二个版本。尽管他们在技术的使用方面也值得商榷，但真正挫败他们的是业务逻辑。他们的第一个版本过早地变得僵化，成为一个维护代价十分高昂的遗留系统。
要想克服这种复杂性，需要非常严格地使用领域逻辑设计方法。在我职业生涯的早期，我幸运地完成了一个非常重视领域设计的项目，这就是我要说的第二个项目。这个项目的领域复杂性与上面提到的那个项目相仿，它最初也小获成功，为贸易机构提供了一个简单的应用程序。但在最初交付之后紧跟着又进行了连续的加速开发。每次迭代都为上一个版本在功能的集成和完善上增加了非常好的新选项。开发团队能够按照贸易商的要求提供灵活性和扩展性。这种良性发展直接归功于深刻的领域模型，它得到了反复精化，并在代码中得以体现。当团队对该领域有了新的理解后，领域模型也随之深化。开发人员之间、开发人员与领域专家之间的沟通质量都得到改善，而且设计不但没有加重维护负担，反而变得易于修改和扩展。
遗憾的是，仅靠认真使用模型并不会使项目达到这样的良性循环。我要说的第三个项目就是这种情况，它开始制订的目标很高，打算基于一个领域模型建立一个全球企业系统，但在经过了几年的屡战屡败之后，不得不降格以求，最终“泯然众人矣”。团队拥有很好的工具，对业务也有较好的理解，也非常认真地进行了建模。但团队却错误地将开发人员的角色独立出来，导致建模与实现脱节，因此设计无法反映不断深化的分析。总之，详细的业务对象设计不能保证它们能够严丝合缝地被整合到复杂的应用程序中。反复的迭代并没有使代码得以改进，因为开发人员的技术水平参差不齐，他们没有认识到他们使用了非正式的风格和技术体系来创建基于模型的对象（这些对象也充当了实用的、可运行的软件）。几个月过去了，开发工作由于巨大的复杂性而陷入困境，而团队对项目也失去了一致的认识。经过几年的努力，项目确实创建了一个适当的、有用的软件，但团队已经放弃了当初的宏伟抱负，也不再重视模型。
复杂性的挑战
很多因素可能会导致项目偏离轨道，如官僚主义、目标不清、资源缺乏，等等。但真正决定软件复杂性的是设计方法。当复杂性失去控制时，开发人员就无法很好地理解软件，因此无法轻易、安全地更改和扩展它。而好的设计则可以为开发复杂特性创造更多机会。
一些设计因素是技术上的。软件的网络、数据库和其他技术方面的设计耗费了人们大量的精力。很多书籍都介绍过如何解决这些问题。大批开发人员很注意培养自己的技能，并紧跟每一次技术进步。
然而很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也是无济于事。成功的设计必须系统地考虑软件的这个核心方面。
本书有两个前提：
（1）在大多数软件项目中，主要的焦点应该是领域和领域逻辑；
（2）复杂的领域设计应该基于模型。
领域驱动设计是一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发。为了实现这个目标，本书给出了一整套完整的设计实践、技术和原则。
设计过程与开发过程
设计书就是讲设计，过程书只是讲过程。它们之间很少互相参考。设计和过程本身就是两个足够复杂的主题。本书是一本设计书，但我相信设计与过程这二者是密不可分的。设计思想必须被成功实现，否则它们就只是纸上谈兵。
当人们学习设计技术时，各种可能性令他们兴奋不已，然而真实项目的错综复杂又会为他们泼上一盆冷水。他们无法用所使用的技术来贯彻新的设计思想，或者不知道何时应该为了节省时间而放弃某个设计方面，何时又应该坚持不懈直至找到一个干净利落的解决方案。开发人员可以抽象地讨论设计原则的应用，而且他们也确实在进行着这样的讨论，但更自然的做法应该是讨论如何完成实际工作。因此，虽然本书是一本有关设计的书，但我会在必要的时候穿越这条人为设置的边界，进入过程的领域。这有助于将设计原则放到一个适当的语境下进行讨论。
虽然本书并不局限于某一种特定的方法，但主要还是面向“敏捷开发过程”这一新体系。特别地，本书假定项目必须遵循两个开发实践，要想应用书中所讲的方法，必须先了解这两个实践。
过去10年中，我在几个业务和技术领域开发了一些复杂的系统。我在设计和开发过程中尝试了一些最佳实践，它们都是面向对象开发高手用过的领先技术。有些项目非常成功，但有几个项目却失败了。成功的项目有一个共同的特征，那就是都有一个丰富的领域模型，这个模型在迭代设计的过程中不断演变，而且成为项目不可分割的一部分。
本书为作出设计决策提供了一个框架，并且为讨论领域设计提供了一个技术词汇库。本书将人们普遍接受的一些最佳实践综合到一起，并融入了我自己的见解和经验。面对复杂领域的软件开发团队可以利用这个框架来系统性地应用领域驱动的设计。
三个项目的对比
谈到领域设计实践对开发结果的巨大影响时，我的记忆中立即就会跳出三个项目，它们就是鲜活的例子。虽然这三个项目都交付了有用的软件，但只有一个项目实现了宏伟的目标——交付了能够满足组织后续需求、可以不断演进的复杂软件。
我要说的第一个项目完成得很迅速，它提供了一个简单实用的Web交易系统。开发人员主要凭直觉开发，但这并没有妨碍他们，因为简单软件的编写并不需要过多地注意设计。由于最初的这次成功，人们对未来开发的期望值变得极高。我就是在这个时候被邀请开发它的第二个版本的。当我仔细研究这个项目时，发现他们没有使用领域模型，甚至在项目中没有一种公共语言，而且项目完全没有一种结构化的设计。项目领导者对我的评价并不赞同，于是我拒绝了这项工作。一年后，这个项目团队陷入困境，无法交付第二个版本。尽管他们在技术的使用方面也值得商榷，但真正挫败他们的是业务逻辑。他们的第一个版本过早地变得僵化，成为一个维护代价十分高昂的遗留系统。
要想克服这种复杂性，需要非常严格地使用领域逻辑设计方法。在我职业生涯的早期，我幸运地完成了一个非常重视领域设计的项目，这就是我要说的第二个项目。这个项目的领域复杂性与上面提到的那个项目相仿，它最初也小获成功，为贸易机构提供了一个简单的应用程序。但在最初交付之后紧跟着又进行了连续的加速开发。每次迭代都为上一个版本在功能的集成和完善上增加了非常好的新选项。开发团队能够按照贸易商的要求提供灵活性和扩展性。这种良性发展直接归功于深刻的领域模型，它得到了反复精化，并在代码中得以体现。当团队对该领域有了新的理解后，领域模型也随之深化。开发人员之间、开发人员与领域专家之间的沟通质量都得到改善，而且设计不但没有加重维护负担，反而变得易于修改和扩展。
遗憾的是，仅靠认真使用模型并不会使项目达到这样的良性循环。我要说的第三个项目就是这种情况，它开始制订的目标很高，打算基于一个领域模型建立一个全球企业系统，但在经过了几年的屡战屡败之后，不得不降格以求，最终“泯然众人矣”。团队拥有很好的工具，对业务也有较好的理解，也非常认真地进行了建模。但团队却错误地将开发人员的角色独立出来，导致建模与实现脱节，因此设计无法反映不断深化的分析。总之，详细的业务对象设计不能保证它们能够严丝合缝地被整合到复杂的应用程序中。反复的迭代并没有使代码得以改进，因为开发人员的技术水平参差不齐，他们没有认识到他们使用了非正式的风格和技术体系来创建基于模型的对象（这些对象也充当了实用的、可运行的软件）。几个月过去了，开发工作由于巨大的复杂性而陷入困境，而团队对项目也失去了一致的认识。经过几年的努力，项目确实创建了一个适当的、有用的软件，但团队已经放弃了当初的宏伟抱负，也不再重视模型。
复杂性的挑战
很多因素可能会导致项目偏离轨道，如官僚主义、目标不清、资源缺乏，等等。但真正决定软件复杂性的是设计方法。当复杂性失去控制时，开发人员就无法很好地理解软件，因此无法轻易、安全地更改和扩展它。而好的设计则可以为开发复杂特性创造更多机会。
一些设计因素是技术上的。软件的网络、数据库和其他技术方面的设计耗费了人们大量的精力。很多书籍都介绍过如何解决这些问题。大批开发人员很注意培养自己的技能，并紧跟每一次技术进步。
然而很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也是无济于事。成功的设计必须系统地考虑软件的这个核心方面。
本书有两个前提：
（1）在大多数软件项目中，主要的焦点应该是领域和领域逻辑；
（2）复杂的领域设计应该基于模型。
领域驱动设计是一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发。为了实现这个目标，本书给出了一整套完整的设计实践、技术和原则。
设计过程与开发过程
设计书就是讲设计，过程书只是讲过程。它们之间很少互相参考。设计和过程本身就是两个足够复杂的主题。本书是一本设计书，但我相信设计与过程这二者是密不可分的。设计思想必须被成功实现，否则它们就只是纸上谈兵。
当人们学习设计技术时，各种可能性令他们兴奋不已，然而真实项目的错综复杂又会为他们泼上一盆冷水。他们无法用所使用的技术来贯彻新的设计思想，或者不知道何时应该为了节省时间而放弃某个设计方面，何时又应该坚持不懈直至找到一个干净利落的解决方案。开发人员可以抽象地讨论设计原则的应用，而且他们也确实在进行着这样的讨论，但更自然的做法应该是讨论如何完成实际工作。因此，虽然本书是一本有关设计的书，但我会在必要的时候穿越这条人为设置的边界，进入过程的领域。这有助于将设计原则放到一个适当的语境下进行讨论。
虽然本书并不局限于某一种特定的方法，但主要还是面向“敏捷开发过程”这一新体系。特别地，本书假定项目必须遵循两个开发实践，要想应用书中所讲的方法，必须先了解这两个实践。
序言回到顶部↑
有很多因素会使软件开发复杂化，但最根本的原因是问题领域本身错综复杂。如果你要为一家人员复杂的企业提高自动化程度，那么你开发的软件将无法回避这种复杂性，你所能做的只有控制这种复杂性。
控制复杂性的关键是有一个好的领域模型，这个模型不应该仅仅停留在领域的表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需的支持。好的领域模型价值连城，但要想开发出好的模型也并非易事。精通此道的人并不多，而且这方面的知识也很难传授。
Eric Evans就是为数不多的一位能够创建出优秀领域模型的人。我是在与他合作时发现他的这种才能的——发现一个客户竟然比我技术更精湛，这种感觉有些奇妙。我们的合作虽然短暂，但却充满乐趣。从那之后我们一直保持联系，我也有幸见证了本书整个“孕育”过程。
本书绝对值得期待。
本书终于实现了一个宏伟抱负，即描述并建立了领域建模艺术的词汇库。它提供了一个参考框架，人们可以用来解释相关活动，并将这门难学的技艺传授给他人。本书在写作过程中，也带给我很多新想法，如果哪位概念建模方面的老手没有从阅读本书中获得大量的新思想，那我反而该惊诧莫名了。
Eric还对我们多年以来学过的知识进行了归纳总结。首先，在领域建模过程中不应将概念与实现割裂开来。高效的领域建模人员不仅应该能够在白板上与会计师进行讨论，而且还应该能与程序员一道编写Java代码。之所以要具备这些能力，一部分原因是如果不考虑实现问题就无法构建出有用的概念模型。但概念与实现密不可分的最主要原因在于，领域模型的最大价值是它提供了一种通用语言，这种语言是将领域专家和技术人员联系在一起的纽带。
我们将从本书中学到的另一个经验是领域模型并不是按照“先建模，后实现”这个次序来工作的。像很多人一样，我也反对“先设计，再构建”这种固定的思维模式。Eric的经验告诉我们，真正强大的领域模型是随着时间演进的，即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。
我衷心希望本书成为一本有影响力的著作，并希望本书能够将如何利用领域模型这一宝贵工具的知识传授给更多的人，从而为这个高深莫测的领域梳理出一个结构，并使它更有内聚力。领域模型对软件开发的控制有着巨大影响，不管软件开发是用什么语言或环境实现的。
最后，也是很重要的一点，我最敬佩Eric的一点是他敢于在本书中谈论自己的一些不成功经历。很多作者都喜欢摆出一副无所不能的架势，有时着实让人不屑。但Eric清楚地表明他像我们大多数人一样，既品尝过成功的美酒，也体验过失败的沮丧。重要的是他能够从成功和失败中学习，而对我们来说更重要的是他能够将所有经验传授给我们。
Martin Fowler
2003年4月
控制复杂性的关键是有一个好的领域模型，这个模型不应该仅仅停留在领域的表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需的支持。好的领域模型价值连城，但要想开发出好的模型也并非易事。精通此道的人并不多，而且这方面的知识也很难传授。
Eric Evans就是为数不多的一位能够创建出优秀领域模型的人。我是在与他合作时发现他的这种才能的——发现一个客户竟然比我技术更精湛，这种感觉有些奇妙。我们的合作虽然短暂，但却充满乐趣。从那之后我们一直保持联系，我也有幸见证了本书整个“孕育”过程。
本书绝对值得期待。
本书终于实现了一个宏伟抱负，即描述并建立了领域建模艺术的词汇库。它提供了一个参考框架，人们可以用来解释相关活动，并将这门难学的技艺传授给他人。本书在写作过程中，也带给我很多新想法，如果哪位概念建模方面的老手没有从阅读本书中获得大量的新思想，那我反而该惊诧莫名了。
Eric还对我们多年以来学过的知识进行了归纳总结。首先，在领域建模过程中不应将概念与实现割裂开来。高效的领域建模人员不仅应该能够在白板上与会计师进行讨论，而且还应该能与程序员一道编写Java代码。之所以要具备这些能力，一部分原因是如果不考虑实现问题就无法构建出有用的概念模型。但概念与实现密不可分的最主要原因在于，领域模型的最大价值是它提供了一种通用语言，这种语言是将领域专家和技术人员联系在一起的纽带。
我们将从本书中学到的另一个经验是领域模型并不是按照“先建模，后实现”这个次序来工作的。像很多人一样，我也反对“先设计，再构建”这种固定的思维模式。Eric的经验告诉我们，真正强大的领域模型是随着时间演进的，即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。
我衷心希望本书成为一本有影响力的著作，并希望本书能够将如何利用领域模型这一宝贵工具的知识传授给更多的人，从而为这个高深莫测的领域梳理出一个结构，并使它更有内聚力。领域模型对软件开发的控制有着巨大影响，不管软件开发是用什么语言或环境实现的。
最后，也是很重要的一点，我最敬佩Eric的一点是他敢于在本书中谈论自己的一些不成功经历。很多作者都喜欢摆出一副无所不能的架势，有时着实让人不屑。但Eric清楚地表明他像我们大多数人一样，既品尝过成功的美酒，也体验过失败的沮丧。重要的是他能够从成功和失败中学习，而对我们来说更重要的是他能够将所有经验传授给我们。
Martin Fowler
2003年4月
媒体评论回到顶部↑
这本书应该出现在每个软件开发人员的书架上。
——Kent Beck，软件开发方法学的泰斗，极限编程的创始人
Eric的这本书太棒太神奇了，他准确地告诉你如何让软件设计满足你理想中的模型需求。……本书读起来趣味无穷，Eric有许多有趣的故事，而且描述起来很有一套。它出版后将成为软件开发人员必读的经典之作。
——Ralph Johnson，《设计模式》的作者
如果你认为自己在面向对象编程中的投资没有收到回报，那么读了本书你就会知道自己漏掉了什么。
——Ward Cunningham， 设计模式和敏捷软件方法的先驱
Eric Evans力证作为开发核心的领域模型的重要性，他搭建了一个稳固的框架并提供了一套实现技术和技巧。这里沉淀下来的是亘古不变的智慧，在应时的方法论都沦为明日黄花后，它依然光华璀璨。
——Dave Collins，Designing Object-Oriented User Interfaces的作者
Eric完全从实战者的角度着笔，描述了无处不用的语言、与用户共享模型的好处、对象生命周期的管理、深度重构的过程和结果，这是对我们这个领域的巨大贡献。
——Luke Hohmann，Beyond Software Architecture的作者
——Kent Beck，软件开发方法学的泰斗，极限编程的创始人
Eric的这本书太棒太神奇了，他准确地告诉你如何让软件设计满足你理想中的模型需求。……本书读起来趣味无穷，Eric有许多有趣的故事，而且描述起来很有一套。它出版后将成为软件开发人员必读的经典之作。
——Ralph Johnson，《设计模式》的作者
如果你认为自己在面向对象编程中的投资没有收到回报，那么读了本书你就会知道自己漏掉了什么。
——Ward Cunningham， 设计模式和敏捷软件方法的先驱
Eric Evans力证作为开发核心的领域模型的重要性，他搭建了一个稳固的框架并提供了一套实现技术和技巧。这里沉淀下来的是亘古不变的智慧，在应时的方法论都沦为明日黄花后，它依然光华璀璨。
——Dave Collins，Designing Object-Oriented User Interfaces的作者
Eric完全从实战者的角度着笔，描述了无处不用的语言、与用户共享模型的好处、对象生命周期的管理、深度重构的过程和结果，这是对我们这个领域的巨大贡献。
——Luke Hohmann，Beyond Software Architecture的作者
加载中...
