领域驱动设计
出版社:清华大学出版社
出版日期:2006-3-1
ISBN:9787302115762
作者:Eric Evans
页数:390页
内容概要
陈大峰，国防科技大学计算机与技术博士，研究方向；分布式计算；研究课题为过程集成工作流。对UML建模、EDOC、工作流和过程集成有深入的研究，曾发表多篇论文和专业文章。目前担任某消息代理中间件产品开发组长，一直使用UML作为设计工具和沟通工具，并取得显著成果。
书籍目录
第Ⅰ部分 让领域模型发挥作用第1章 消化知识1.1 有效建模的因素1.2 知识消化1.3 持续学习1.4 知识丰富的设计1.5 深层模型第2章 交流及语言的使用2.1 通用语言2.2 利用对话改进模型2.3 一个团队，一种语言2.4 文档和图2.4.1 书面的设计文档2.4.2 执行的基础2.5 说明性模型第3章 将模型和实现绑定3.1 模型驱动设计3.2 建模范型和工具支持3.3 突出主旨：为什么模型对用户很关键3.4 实践型建模人员第Ⅱ部分 模型驱动设计的构建块第4章 分离领域4.1 分层架构4.1.1 层间的联系4.1.2 架构框架4.2 模型属于领域层4.3 其他种类的隔离第5章 软件中的模型描述5.1 关联5.2 实体(又称引用对象)5.2.1 实体建模5.2.2 设计标识操作5.3 值对象5.3.1 设计值对象5.3.2 设计包含值对象的关联5.4 服务5.4.1 服务和分隔的领域层5.4.2 粒度5.4.3 访问服务5.5 模块(包)5.5.1 敏捷的模块5.5.2 基础结构驱动打包的缺陷5.6 建模范式5.6.1 对象范式的优势5.6.2 对象世界中的非对象5.6.3 在混合范式中使用模型驱动设计第6章 领域对象的生命周期6.1 聚合6.2 工厂6.2.1 工厂及其应用场所的选择6.2.2 只需构造函数的情况6.2.3 接口的设计6.2.4 如何放置不变量的逻辑6.2.5 实体工厂与值对象工厂6.2.6 存储对象的重建6.3 仓储6.3.1 查询仓储6.3.2 了解仓储实现的必要性6.3.3 实现仓储6.3.4 在框架内工作6.3.5 与工厂的关系6.4 为关系数据库设计对象第7章 使用语言：扩展示例7.1 货物运输系统概述7.2 隔离领域：系统简介7.3 区分实体和值对象7.4 运输领域中的关联设计7.5 聚合的边界7.6 选择仓储7.7 场景概述7.7.1 应用特性示例：改变一件货物的目的地7.7.2 应用特性示例：重复业务7.8 对象的创建7.8.1 Cargo的工厂和构造函数7.8.2 添加一个Handling Event7.9 停下来重构：Cargo聚合的另一种设计7.10 运输模型中的模块7.11 引入新特性：配额检查7.11.1 连接两个系统7.11.2 改进模型：划分业务7.11.3 性能调整7.12 小结第Ⅲ部分 面向更深层理解的重构第8章 突破8.1 关于突破的故事8.1.1 中看不中用的模型8.1.2 突破8.1.3 更深层的模型8.1.4 冷静的决定8.1.5 成效8.2 时机8.3 着眼于根本8.4 尾声：一连串的新理解第9章 隐含概念转变为显式概念……第10章 柔性设计第11章 应用分析模式第12章 把设计模式和模型联系起来第13章 向更深层理解重构第Ⅳ部分 战略性设计第14章 维护模型完整性第15章 精炼第16章 大比例结构第17章 综合应用战略性设计第18章 尾声附录A 关于模式附录B 术语表附录C 参考文献附录D 关系图
作者简介
领域建模已被业界普遍认为是软件设计成败的关键。通过领域建模，软件开发人员能够展示丰富的功能并将这些功能实现为真正满足用户需要的软件。尽管领域建模非常重要，但市面上介绍如何将有效的领域建模结合到软件开发过程中的著作却非常少。 本书就是为此目的而编写的。它向读者系统地讲述了领域驱动设计的方法，介绍了大量优秀的设计示例、技术经验以及用于处理复杂领域软件工程的基本原则。本书做到了设计和开发实践相结合，在介绍领域驱动设计的同时，还提供了大量的Java示例。 通过本书，读者将获得对领域驱动设计的总体认识，了解领域驱动设计中涉及的关键原则和术语。 面向对象的开发人员、系统分析师以及设计师在深入思考领域问题时，能够从本书中获得一定的指导，从而建立丰富而有用的领域模型，并将这些模型转化为高质量和持久的软件实现。
图书封面
发布书评
精彩书评 (总计7条)
-
《领域驱动设计》一书是领域模型领域的代表作，被很多牛人推荐，其中的概念还需要在思考和实践中逐步理解。书中描述的一些现象有些与我们类似，比如越来越多的领域规则被嵌入到查询代码中，或者直接就不见了。领域逻辑跑到查询代码和客户代码中去了，而实体和值对象变成了纯粹的数据容器。大部分数据访问基础结构的技术复杂性，很快使得客户代码陷入混乱，最终开发人员只好抛弃领域层，把模型变成一个摆设。以下将针对一些非技术问题进行一些记录，方便以后查阅思考。* 如果程序员对领域较为熟悉，他们便可以使得软件保持能够继续扩展的良好状态，但是如果程序员对于该领域不敢兴趣，他们知道应用程序应该做什么，却不了解其背后的原理。这样做虽然能够建立一个有用的软件，但是项目永远不会具有能够从前期特征能推导出更加强大的新特征的能力。* 领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。* 很多原因都会造成软件开发的复杂性，然而其核心则是由于问题领域本身的复杂性。控制复杂问题的关键是建立一个好的领域模型，它越过问题域的表象介绍其底层的结构，给软件开发人员提供所需的方法。* 模型驱动设计不仅要求我们的设计能够将概念表达出来，还应该能够被高效的实现。一个领域模式不仅仅是用UML图表达出来的优雅的想法，它还应该为模型驱动设计中的某个编程问题提供解决方案。当我们的模型应该恰当时，我们就可以深入下去，挖掘出一整套解决某种领域建模问题的思路。而且，这种寻找高效实现的经验的不断积累，也能使我们受益匪浅。* 软件的最终目的是为用户提供服务，但是，它首先必须为开发人员服务。如果软件的行为非常复杂，但是又缺乏良好的设计，那它就会变得难以重构和组合。由于开发人员不能够确切的预知计算的全部内涵，重复问题就产生了。如果设计元素都是整块的、无法重新组合的部分，重复就是不可避免的了。我们可以对那些类和方法进行分解使之便于重用，但这样一来各个小部分分别有什么作用又变得难以跟踪了。一个缺乏清晰设计的软件，单是看到其中的混乱结构就会让开发人员头脑发晕，更不用说对设计进行修改（那只会使设计更加混乱），有时甚至会由于意料之外的依赖关系而导致设计完全无法工作。这种脆弱性导致我们无法构造出行为更加丰富的系统（除非系统的规模相当小），也阻碍了重构和迭代精化的进行。* 随着项目开发的进行，我们应该感到速度越来越快，而不是感到包袱越来越层沉。这就要求我们的设计能让人乐于使用，也能很容易的适应改变。这就是柔性设计。* 模型的选择取决于3个基本的用途： 模型与设计核心的相互塑形、模型是所有团队成员所使用语言的核心、模型用来提炼知识* 知识消化并不是一个孤立的活动，它是由开发团队与领域专家共同合作，由开发人员领导的。知识消化过程必须探索模型选项，并将它们精化为使用的软件元素。* 那些没有领域模型，只是靠编写代码来完成一个又一个功能的项目，不能获得知识消化与交流带来的益处。* 领域模型的不断精化使得开发人员不断地学习他们的重要业务原理，而不是机械的产生新的功能。* 模型关注的是需求分析，它与编程和设计相互影响。* 重组会打散团队，知识也会再次分散。仅仅交付了代码而没有传递知识的工作方式使得一些关键的子系统无据可依。使用典型的设计方法时，代码和文档都不能用有效的方式表达出人们辛苦得到的知识，因此当这种口头上的惯例由于任何原因被打破时，知识也就遗失了。* 高效率的团队依靠学习，有意识的增长自己的知识，这意味着提高技术知识以及一般的领域建模技能，也包括学习所从事的特定领域。* 使用术语及关系来反映领域的内涵。基于模型的交流提高编写文档的实用性。* 要将模型作为语言的骨干。使用了通用语言，模型就不仅仅是一个设计工作了。它整合到开发人员与领域专家所做的每一件事中。* 一定要记住模型并不是图，图的目的是帮助表达和解释模型。* 说明性模型的图形带有它所表示模型的自然语言解释。一起查看两种图形（说明性模型和类图模型）要比单独查看任何一种更容易理解。* 一个缺乏设计基础概念的软件最多只能是一个能够做游泳的事情却不能清楚解释它的行为的机械装置。* 建模与编程的完全分离是不可行的。* 纯粹的分析模型甚至不能够达到其理解领域的主要目标，因为重要的发现往往出现在设计/实现过程中。模型驱动设计抛弃了分裂分析模型与设计的做法，而是寻找一个单独的模型来满足着两方面的要求。* 将分析、建模、设计和编码的职责完全隔离起来，会阻碍模型驱动设计。分开会造成：交接时遗漏了模型的一些意图；模型与实现和技术之间的相互作用个所得到的反馈过于间接。* 负责建模的技术人员必须花时间接触代码，而不论他是否在项目中担当主要角色。任何负责代码修改的人员都必须学习通过代码表达模型。每个开发人员都必须参与一些级别的模型讨论中，并与领域专家接触。* 解决来自领域方面的软件部分通常只占整个软件系统的一小部分，这与它的重要性相比是不成比例的。我们需要把领域对象跟系统的其他功能分离出来，才能够避免将领域概念与其他软件技术相关的概念混淆或者在系统的庞大中失去了对领域的把握。* 是领域层而不是应用层负责提供基本的规则。* 在应用一个框架是，开发团队应该首先明确它的目标：创建一个实现来表示一个领域模型并且用这个实现来解决重要的问题。* 不受限制的数据库查询实际上会破坏领域对象和聚合的封装。* 一般来说，不要与框架对着干。寻找合适的方法来保持领域驱动设计的基本方向。如果框架与设计发生矛盾的话，在一些细节问题上顺其自然。寻找领域驱动设计的概念与框架概念有哪些相近之处。当然，这里的假设是我们除了使用该框架之外别无选择。* 建模和设计不是一个匀速向前的过程，如果不频繁重构，利用新的理解来改进模型和设计，我们就会逐渐变的寸步难行。* 约束构成了模型概念中特别重要的一种类型。* 流程是应该被显示的描述出来还是应该隐藏起来？区分的要点很简单：这个流程是领域专家所谈论的流程，还是仅仅是计算机程序机制的一部分？ -
Google翻译还是有道翻译的。。弄明白后想竖个中指，那么简单的概念，翻译的那么复杂。Google翻译还是有道翻译的。。弄明白后想竖个中指，那么简单的概念，翻译的那么复杂。 -
不要过于关注书中描述的具体技术、设计方法领域模型贯穿概念模型、逻辑和物理设计模型，贯穿需求采集、分析、设计、实现，到测试部署这一整个开发过程，应该注意从整体角度来理解领域驱动的思想需求采集时与业务专家的沟通已经开始领域模型的建模工作；对需求深入的分析整理与业务专家探讨确认，目的是构造出扩展性比较好的弹性模型；设计模型与领域模型不要独立开来，尽量与领域模型保持比较高的匹配程度，不要让太多的设计细节扰乱领域模型的表达力；代码实现尽量将与领域逻辑无关的处理分离或独立开来，尽量让代码比较简洁、清晰的描述领域逻辑；后续的迭代是基于对领域逻辑深层次的理解来完善领域模型，向深度模型(deep model)发展；
精彩短评 (总计44条)
-
领域驱动设计开山立派之作，必读 -
:
TP311.5/2204 -
感觉读起来有些吃力，可能是经验还不足吧。 -
对传统软件开发不熟悉看得有点吃力…颇有启发的，只是感觉未能完全吃透。 :( -
领域驱动设计--软件核心复杂性应对之道 -
非常好 -
第四部分对没有大型软件建模及设计经验的人来说太晦涩了。 -
非软件开发，使用某些特定的领域建模软件或程序构建领域模型。 -
有点玄妙的感觉，呵呵，看晕了 -
理解业务和处理好业务逻辑才是软件设计的重点 -
读过精简版， 觉得不错。但是很多东西都不能理解。 -
大尺度问题的复杂性 -
翻译得相当搓 -
可能我水平太低了吧 -
领域建模必读。 -
【绝版】领域建模的书籍。比较催眠。还行吧，里面举的例子没细看，后面又谈到了关于如何组织团队的管理方面的问题。可能需要细细品味吧。 -
重读重读再重读 -
领域驱动思想+方法，个人觉得重点在于思想，方法可以根据实际情况灵活运用，盯着方法而轻视了思想就是根本没有理解领域驱动，那些说“××代码这样写不是领域驱动”都是舍本逐末。 -
不自觉的在自己的项目中已经应用了一些其中的方法，但我总体上感觉，书中有不少东西我还没有理解透彻，可能还是“阅历”的问题吧！
总之，这是一本好书！ -
如果要提高，必须看的一本书 -
应用复杂业务的应用系统开发之道，整合了一些原有的方法，例子不是很清晰，估计要多看几遍。 -
不错的书。OO思想。jdon的推荐
还没有吸收消化呀
道道道 呵呵呵 -
错译颇多 -
翻译的有点罗嗦，不如精简版。 -
DDD的发源书。 -
中文翻译一般，建议直接看英文版 -
赞 -
内容不错 翻译还可以 -
打通软件设计的任督二脉.... -
最好的软件设计开发经典之一 -
领域驱动入门 -
领域驱动设计显然已经超越了目前的技术发展水平，进入一种纯理论演绎的方式，随着动态语言、SOA、组件化技术和AOP的发展，技术基础的完善使得领域设计越来越接近实际开发 -
好书，但也相当的晦涩，功力还不够，深入的理解需要大量的实践和思考。 -
不太好评价， 某些章节太抽象了。 -
还没有读完 -
说实话，挺空洞的。不如《UML和模式应用》好。 -
可惜。 这本书后来搬家的时候找不到了。 -
看过第一遍，没有理解。2009APR看来第二遍，有1/3没懂，特别是"大比例结构" -
领域模型让开发人员和领域专家相互沟通，互补互成... -
看过infoq的精简版 -
技术术语与业务术语间存在沟通上的天堑，领域模型术语为天堑搭上了桥梁。领域表达核心的业务规则和流程，和具体的应用无关。比如RFC协议、USB规范、业务专家对业务的描述等等都属于领域知识。 -
对业务建模大有益处 -
05 -
其实没有那么好。。。嚼头罢了