领域驱动设计:处理软件核心的复杂性
- 通过Eric Evans
- 2003年8月20日出版addison - wesley专业．
描述
- 版权2004
- 尺寸:7" x 9-1/4"
- 页:560
- 版本:1
- 书
- ISBN-10: 0-321-12521-5
- ISBN-13: 978-0-321-12521-7
将有效的领域建模合并到软件开发过程中
软件设计思想领袖和领域语言的创始人Eric Evans为领域驱动设计提供了一种系统的方法，提出了一套广泛的设计最佳实践，基于经验的技术，以及促进面向复杂领域的软件项目开发的基本原则。交织系统设计和开发实践，本书结合了基于实际项目的许多示例，以说明领域驱动设计在现实世界软件建模和开发中的应用。
- 域模型第1部分概述了领域驱动开发的目标，定义了术语，并概述了使用领域模型来驱动通信和设计的含义
- 模型驱动设计:第2部分将面向对象领域建模的最佳实践核心浓缩为一组基本构建块，并将重点放在保持模型和实现彼此一致的各种决策上，每个决策都加强了对方的有效性
- 重构:第三部分深入探讨了可以指导选择的建模原则，以及帮助指导搜索的技术
- 战略设计第四部分探讨了应用于整个系统的三个原则:上下文、蒸馏和大规模结构
在整本书中，讨论不是用过分简化的“问题”来说明的，而是用取自实际项目的现实例子来说明的。有了这本书，面向对象的开发人员、系统分析人员和设计人员将获得他们需要的指导，以组织和集中他们的工作，创建丰富而有用的领域模型，并将这些模型转化为高质量的、持久的软件实现。
“这本书读起来很有趣。埃里克有很多有趣的故事，他有一种文字的方式。我认为这本书是软件开发人员的必备读物——它是未来的经典。”
——拉尔夫·约翰逊，《。设计模式
示例内容
在线示例章节
可下载样章
下载样章与这个标题相关。
样页
下载样例页面(包括第一章及索引)
目录表
前言。
前言。
致谢
1 .使领域模型发挥作用。
1.处理知识。有效建模的要素。
知识处理。
持续学习。
Knowledge-Rich设计。
深度模型。
2.沟通和语言的使用。无处不在的语言。
大声模仿。
一个团队，一种语言。
文件和图表。
书面设计文件。
可执行的基石。
解释模型。
3.绑定模型和实现。模型驱动的设计。
建模范例和工具支持。
让骨骼展示:为什么模型对用户很重要。
实际的建模。
2模型驱动设计的构建块。
4.隔离域。分层架构。
关联图层。
体系结构框架。
领域层是模型所在的地方。
智能UI“反模式”
其他类型的隔离。
5.用软件表达的模型。关联。
实体(又名引用对象)。
建模的实体。
标识操作的设计。
值对象。
设计值对象。
设计包含值对象的关联。
服务。
服务和隔离域层。
粒度。
访问服务。
模块(又名包)。
敏捷的模块。
基础设施驱动打包的陷阱。
建模范例。
为什么对象范式占主导地位。
对象世界中的非对象。
混合范式时坚持模型驱动设计。
6.域对象的生命周期。骨料。
工厂。
选择工厂和厂址。
当你只需要构造函数时。
设计界面。
不变逻辑何去何从?
实体工厂vs值对象工厂。
重构存储对象。
存储库。
查询存储库。
客户端代码忽略存储库实现;开发者则不然。
实现存储库。
在框架内工作。
与工厂的关系。
为关系数据库设计对象。
7.使用语言:一个扩展的例子。介绍货物运输系统。
隔离域:引入应用程序。
区分实体和值对象。
角色和其他属性。
航运领域的关联设计。
聚合边界。
选择存储库。
演练场景。
示例应用程序功能:更改货物的目的地。
示例应用程序特点:重复业务。
对象创建。
货物工厂和建造商。
添加处理事件。
暂停重构:货物聚合的另一种设计。
运输模型中的模块。
引入一个新功能:分配检查。
连接两个系统。
增强模型:细分业务。
性能调优。
最后一看。
3重构以获得更深入的洞察力。
8.突破。一个突破的故事。
一个体面的模特，然而....
的突破。
更深层次的模型。
发人深省的决定。
回报。
的机会。
专注于基础。
后记:一连串的新见解。
9.使隐式概念显化。挖掘概念。
倾听语言。
细看尴尬。
考虑矛盾。
读这本书。
尝试，再尝试。
如何为不太明显的概念建模。
明确的约束。
进程作为域对象。
规范
应用和实现规范。
10.柔软的设计。寓意接口。
没有副作用的函数。
断言。
概念上的轮廓。
独立的类。
操作的关闭。
声明式设计。
领域特定语言。
声明式的设计风格。
以声明式风格扩展规范。
攻角。
分割子域。
尽可能利用已确立的形式。
11.应用分析模式。12.将设计模式与模型关联起来。
战略(又名政策)。
合成的。
为什么不是FLYWEIGHT?
13.深入洞察的重构。启动。
探索团队。
现有技术。
面向开发者的设计。
时机。
危机即机遇。
四、战略设计。
14.维护模型完整性。限界上下文。
在有限的环境中识别碎片
持续集成。
环境地图。
在上下文边界进行测试。
组织和记录上下文地图。
有界上下文之间的关系。
共享内核。
客户/供应商开发团队。
墨守成规。
反腐败层。
设计反腐败层的接口。
实现反腐败层。
警世故事。
分道扬镳。
打开主机服务。
语言出版。
统一一头大象。
选择你的模型上下文策略。
团队决策或更高级别。
把自己置于环境中。
改变边界。
接受我们无法改变的:描绘外部系统。
与外部系统的关系。
设计中的系统。
以独特的模式迎合特殊需要。
部署。
权衡。
当你的项目已经在进行中。
转换。
合并上下文:独立的方式共享内核。
合并上下文:共享内核-持续集成。
逐步淘汰遗留系统。
开放主机服务发布的语言。
15.蒸馏。核心域。
选择核心。
谁在工作?
蒸馏的升级。
通用的子域。
通用并不意味着可重复使用。
项目风险管理。
领域愿景声明。
突出核心。
蒸馏文档。
标记的核心。
蒸馏文档作为过程工具。
衔接机制。
通用子域与内聚机制。
当一个机制是核心领域的一部分。
提炼为声明式风格。
种族隔离的核心。
创建隔离核心的成本。
不断发展的团队决策。
抽象的核心。
深度模型提炼。
选择重构目标。
16.大规模的结构。发展秩序。
系统的隐喻。
“天真的隐喻”和为什么我们不需要它。
责任层。
选择合适的图层。
知识水平。
可插入组件框架。
结构应该有多大的限制?
朝着合适的结构重构。
极简主义。
沟通和自律。
重组产生柔性设计。
蒸馏减轻了负荷。
17.整合战略。结合大规模结构和有限的上下文。
结合大规模结构和蒸馏。
第一次评估。
谁制定战略?
来自应用程序开发的紧急结构。
以客户为中心的架构团队。
战略设计决策的六个要素。
技术框架也是如此。
当心“总体规划”。
结论。附录:本书模式的使用。
术语表。
参考文献
照片学分。
指数。0321125215 t08272003
前言
领先的软件设计师已经将领域建模和设计视为关键主题至少有20年了，但令人惊讶的是，关于需要做什么或如何做的文章很少。尽管它从未被清晰地表述过，但一种哲学已经在对象社区中作为一种暗流发展起来，我称之为“领域驱动设计”。188bet备用网
在过去的十年里，我一直专注于开发几个业务和技术领域的复杂系统。我尝试了设计和开发过程中的最佳实践，因为它们是从面向对象开发社区的领导者那里出现的。188bet备用网我的一些项目非常成功;有几个失败了。成功的一个共同特征是丰富的领域模型，它通过设计的迭代而发展，并成为项目结构的一部分。
本书为制定设计决策提供了框架，并为讨论领域设计提供了技术词汇。它是广泛接受的最佳实践以及我自己的见解和经验的综合。面对复杂领域的项目可以使用这个框架系统地进行领域驱动设计。
对比三个项目
在我的记忆中，有三个项目是领域设计实践对开发结果产生戏剧性影响的生动例子。尽管这三个项目都交付了有用的软件，但是只有一个实现了它的宏伟目标，并且交付了复杂的软件，这些软件能够不断发展以满足组织的持续需求。
我看到一个项目很快就推出了一个有用的、简单的基于网络的交易系统。开发人员都是凭感觉做事，但简单的软件可以在不关注设计的情况下编写出来。由于最初的成功，人们对未来的发展寄予了极高的期望。也就是在这个时候，我接到了第二个版本的工作邀请。当我仔细观察时，我发现它们缺乏领域模型，甚至缺乏项目上的公共语言，并且背负着非结构化的设计。因此，当项目负责人不同意我的评估时，我拒绝了这份工作。一年后，他们发现自己陷入了困境，无法推出第二个版本。尽管他们对技术的使用并不堪称典范，但战胜他们的是业务逻辑。他们的第一个版本过早地僵化为一个高维护的遗产。
要解除复杂性的限制，就需要采用更严肃的方法来设计领域逻辑。在我职业生涯的早期，我很幸运地参与了一个强调领域设计的项目。这个项目，在一个至少和上面一样复杂的领域，也以适度的初步成功开始，为机构交易者提供了一个简单的应用程序。但是，在这一交付之后，又相继加速了发展。每个连续的迭代都为功能的集成和细化打开了令人兴奋的新选项。该团队能够灵活地响应交易者的需求和扩展能力。这个向上的轨迹直接归因于一个精深的领域模型，它在代码中被反复细化和表达。当团队获得对领域的新见解时，模型就加深了。开发人员之间以及开发人员与领域专家之间的沟通质量得到了改善，并且设计不再强加更重的维护负担，而是变得更容易修改和扩展。
不幸的是，并非所有以这种意图开始的项目都能达到这种良性循环。我加入的一个项目以建立基于领域模型的全球企业系统的崇高愿望开始，但最终得到了令人失望的结果。这个团队有很好的工具，对业务有很好的理解，并且对建模给予了认真的关注。但是开发人员角色的分离导致了模型和实现之间的脱节，因此设计没有反映正在进行的深入分析。在任何情况下，详细业务对象的设计都不够严格，无法支持在复杂的应用程序中组合它们。由于开发人员的技能水平参差不齐，并且对所需的特定类型的严格性没有清晰的理解，重复的迭代并没有产生代码的改进。随着时间的推移，开发工作陷入了复杂性的泥潭，团队失去了对系统的凝聚力。经过多年的努力，该项目确实产生了适度的、有用的软件，但是放弃了早期的目标和模型焦点。
当然，很多事情会使项目偏离轨道，官僚主义、不明确的目标、缺乏资源等等，但是设计的方法在很大程度上决定了软件的复杂程度。当复杂性失去控制时，软件就不能再被很好地理解，从而不能很容易地进行更改或扩展。相比之下，一个好的设计可以从这些复杂的功能中创造机会。
这些设计因素中有一些是技术性的，在网络、数据库和软件的其他技术层面的设计中已经投入了大量的精力。关于如何解决这些问题的书已经写出来了。开发人员已经培养了他们的技能。
然而，许多应用程序最重要的复杂性并不是技术上的。它在领域本身，用户的活动或业务中。如果在设计中没有处理这个领域的复杂性，那么基础结构技术是否设计得很好就无关紧要了。一个成功的设计必须系统地处理软件的这个中心方面。
这本书的前提是
- 对于大多数软件项目，主要的焦点应该放在领域和领域逻辑上。
- 复杂的领域设计应该基于模型。
- 领域驱动设计是一种思维方式和一组优先级，旨在加速必须处理复杂领域的软件项目。为了实现这一目标，本书提出了一套广泛的设计实践、技术和原则。
设计与开发过程
设计的书。过程的书。他们甚至很少互相提及。每个问题本身都是一个复杂的话题。这是一本设计书。但我认为，如果设计概念要成功地付诸实践，而不是在学术讨论中干涸，这两个问题是不可分割的。当人们学习设计技术时，他们会对各种可能性感到兴奋，但随后真正项目的混乱现实就会降临到他们身上。他们不知道如何将新的设计理念与他们必须使用的技术相结合。或者他们不知道什么时候该担心某个特定的设计方面，什么时候该为了时间考虑而放手。虽然可以与其他团队成员抽象地讨论设计原则的应用，但更自然的是讨论我们一起做的事情。 So, while this is a design book, I'm going to barge right across that artificial boundary when I need to. This will place design in the context of a development process.
这本书并不针对某个特定的方法，而是面向“敏捷开发过程”这个新家族。具体地说，它假设项目中有几个过程实践。这两个实践是应用本书方法的先决条件。
- 迭代开发。迭代开发的实践已经被提倡和实践了几十年，它是敏捷开发方法的基石。在敏捷开发和极限编程的文献中有许多很好的讨论，其中包括Cockburn1998和Beck 1999。
- 开发人员和领域专家之间的密切关系。领域驱动的设计将大量的知识分解成一个模型，这个模型反映了对领域的深刻洞察和对关键概念的关注。这是了解领域的人员和知道如何构建软件的人员之间的协作。因为它是迭代的，所以这种协作必须贯穿整个项目的生命周期。
极限编程(XP)，由Kent Beck、Ward Cunningham和其他Beck2000构想，是敏捷过程中最突出的，也是我使用最多的。为了使讨论具体化，我将在全书中使用XP作为讨论设计与过程交互的基础。所说明的原则很容易适用于其他敏捷过程。
近年来，出现了一种对复杂开发方法的反抗，这种方法用无用的、静态的文档和强迫性的前期规划和设计给项目带来负担。相反，敏捷过程，比如XP，强调应对变化和不确定性的能力。
XP认识到设计决策的重要性，但强烈反对预先设计。相反，它付出了令人钦佩的努力来增加沟通，并增加了项目快速改变方向的能力。有了这种反应能力，开发人员可以在项目的任何阶段使用“可以工作的最简单的东西”，然后不断重构，进行许多小的设计改进，最终达到符合客户真正需求的设计。
对于一些过度的设计爱好者来说，这是一剂急需的解毒剂。项目陷入了没有什么价值的繁琐文件中。他们遭受了“分析瘫痪”，如此害怕设计不完美，以至于他们根本没有取得任何进展。有些事情必须改变。
不幸的是，其中一些新的流程思想很容易被误解。每个人对“最简单”都有不同的定义。如果没有设计原则来指导这些小的重新设计，持续的重构可能会产生一个难以理解或更改的代码库——与敏捷性相反。而且，虽然对未预料到的需求的恐惧经常导致过度工程，但避免过度工程的尝试可能会发展成另一种恐惧:对任何深入设计思考的恐惧。
实际上，XP最适合具有敏锐设计意识的开发人员。XP过程假定您可以通过重构来改进设计，并且您将经常且快速地这样做。但是设计选择使重构本身变得更容易或更难。XP过程试图增加团队沟通。但模型和设计选择澄清或混淆沟通。我们需要的是一种能够发挥其作用的领域建模和设计方法。
这本书将设计和开发实践交织在一起，并说明了领域驱动设计和敏捷开发是如何相互加强的。在敏捷开发过程的上下文中，一个成熟的领域建模方法将加速开发。过程与领域开发的相互关系使得这种方法比在真空中处理“纯”设计更实用。
这本书的结构
全书分为四个主要部分:
第一部分:使用领域模型介绍领域驱动开发的基本目标，这些目标将在后面的部分中激励实践。由于软件开发有如此多的方法，第1部分定义了术语，并概述了将领域模型置于驱动通信和设计的角色中的含义。
第二部分:模型驱动设计的构建模块将面向对象领域建模的核心最佳实践压缩为一组基本构建块。本节的重点是在模型和实际运行的软件之间架起桥梁。共享这些标准模式为设计带来了秩序，并使团队成员更容易理解彼此的工作。使用标准模式还建立了一种公共语言，所有团队成员都可以使用它来讨论模型和设计决策。
但本节的主要观点是关于保持模型和实现相互一致，增强彼此有效性的决策。这种对齐需要注意单个元素的细节。这种小规模的精心制作为开发人员提供了一个稳定的平台来应用第三部分和第四部分的建模方法。
第三部分:深入洞察的重构超越构建模块的挑战，将它们组装成提供回报的实用模型。本节强调发现过程，而不是直接跳到深奥的设计原则。有价值的模型不会立即出现。它们需要对领域有深刻的理解。这种理解来自于深入研究，基于一个可能幼稚的模型实现初始设计，然后一次又一次地对其进行转换。每当团队获得洞察力时，就会转换模型以揭示更丰富的知识，并重构代码以反映更深层次的模型，并使其对应用程序可用。然后，每隔一段时间，这种“洋葱皮”就会带来突破更深层模式的机会，随之而来的是一系列深刻的设计变化。
探索本质上是开放式的，但它不一定是随机的。第三部分深入探讨了可以指导选择的建模原则，以及帮助指导搜索的技术。
第四部分:战略设计处理在复杂系统、大型组织、与外部系统和遗留系统的交互中出现的情况。本节探讨了应用于整个系统的三个原则:有界上下文、蒸馏和大规模结构。战略设计决策是由团队做出的，甚至是团队之间的决策。战略设计使第1部分的目标能够在更大的范围内实现，例如大型系统或适合企业范围网络的应用程序。
在整本书中，讨论都用来自实际项目的现实例子来说明，而不是过度简化的“玩具”问题。
这本书的大部分内容都是作为一组“模式”编写的。读者应该能够完全理解材料，而不必担心这个装置，但那些对模式的风格和格式感兴趣的人可以阅读附录A。
这本书是为谁写的
本书主要是为面向对象软件的开发人员编写的。软件项目团队的大多数成员都可以从它的某些部分中受益。对于那些正在做一个项目的人来说，这是最有意义的，因为他们正在尝试做一些事情，或者已经有了丰富的经验。一些面向对象建模的知识对于从本书中获益是必要的。示例包括UML图和Java代码，因此在基本层次上阅读这些语言的能力是重要的，但是掌握UML或Java的细节是没有必要的。极限编程的知识将为开发过程的讨论增加视角，但是没有背景知识的讨论应该是可以理解的。
对于中级软件开发人员，已经了解一些面向对象设计并且可能读过一两本软件设计书籍的读者来说，本书将填补空白，并提供对象建模如何适应软件项目的实际生活的视角。它将帮助中级开发人员将复杂的建模和设计技能应用于实际问题。高级或专业的软件开发人员应该对处理域的综合框架感兴趣。系统化的设计方法将帮助他们领导团队沿着这条道路前进。连贯的术语将有助于他们与同龄人交流。
不同背景的读者可以选择不同的阅读路径，将重点转移到不同的地方。我建议所有读者从第1部分和第1章的介绍开始。这本书是一本叙事性的书，可以从头读到尾，也可以从任何一章的开头开始读。一个已经掌握了一些主题的略读者应该能够通过阅读标题和黑体字来获取要点。一个非常高级的读者可能想略读第一和第二部分，可能对第三和第四部分最感兴趣。
除了这些核心读者之外，本书还会引起分析人员和相对技术性的项目经理的兴趣。分析人员可以利用模型和设计之间的联系，在“敏捷”项目的环境中做出更有效的贡献。分析人员也可以使用战略设计的一些原则来更好地集中和组织他们的工作。
项目经理应该对强调使团队更有效和更专注于设计对业务专家和用户有意义的软件感兴趣。而且，由于战略设计决策与团队组织和工作风格相关，这些设计决策必然涉及项目的领导，并对项目的轨迹产生重大影响。
虽然理解领域驱动设计的开发人员个人将获得有价值的设计技术和观点，但当团队加入应用领域驱动设计方法并将领域模型移动到项目的中心时，最大的收获就来了。团队成员将共享一种语言，这种语言丰富了他们的交流，并使其与软件保持联系。它们将生成与模型同步的实现，为应用程序开发提供杠杆作用。他们将分享不同团队的设计工作如何关联的地图，并将系统地将注意力集中在对组织最独特和最有价值的特征上。
领域驱动的设计是一项困难的技术挑战，它可以在大多数软件项目开始固化为遗留项目的阶段带来巨大的、开放的机会。
埃里克·埃文斯，旧金山，加利福尼亚，2003年3月
http://domainlanguage.com
0321125215 p04092003
前言
有许多事情使软件开发变得复杂。但是这种复杂性的核心是问题域本身的本质复杂性。如果您试图将自动化添加到复杂的人类企业中，那么您的软件无法避开这种复杂性——它所能做的就是控制它。
控制复杂性的关键是一个好的领域模型，该模型通过引入底层结构而超越了领域的表面视觉，从而为软件开发人员提供了所需的杠杆。一个好的领域模型可能非常有价值，但它不是一件容易做到的事情。很少有人能做好，而且很难教。
Eric Evans是少数几个能够很好地创建领域模型的人之一。我是在和他一起工作时发现这一点的——当你找到一个比你更有技能的客户时，那是一段美妙的时光。我们的合作时间很短，但非常有趣。从那以后，我们一直保持联系，我看着这本书慢慢地孕育。
等待是值得的。
这本书已经发展成为满足一个巨大目标的书:描述和建立一个关于领域建模艺术的词汇表。提供一个参考框架，通过这个框架，我们可以解释这个活动，也可以教授这个很难学习的技能。这本书在成型的过程中给了我许多新的想法，如果即使是概念建模的老手也没有从这本书中获得大量的新想法，我会感到惊讶。
埃里克还巩固了我们多年来学到的许多东西。首先，在领域建模中，您不应该将概念与实现分开。一个有效的领域建模者不仅可以与会计一起使用白板，还可以与程序员一起编写Java。这在一定程度上是正确的，因为你不能建立一个有用的没有考虑实现问题的概念模型。但是概念和实现应该在一起的主要原因是:领域模型的最大价值在于它提供了一个无处不在的语言这将领域专家和技术人员联系在一起。
您将从本书中学到的另一个教训是，领域模型不是首先建模然后实现的。像许多人一样，我已经开始拒绝“设计，然后构建”的分阶段思维。但是Eric的经验告诉我们，真正强大的领域模型是随着时间的推移而发展的，即使是最有经验的建模者也会发现，他们在系统的初始发布之后才会获得最好的想法。我认为，也希望，这将是一本极具影响力的书。它将为一个非常棘手的领域增加结构和凝聚力，同时教会很多人如何使用一个有价值的工具。领域模型可以在控制软件开发方面产生重大影响——无论在何种语言或环境中实现它们。
最后一个重要的想法。在这本书中，我最尊重的一点是埃里克不害怕谈论他不成功的时候。大多数作家都喜欢保持一种无私的无所不能的神气。埃里克说得很清楚，和我们大多数人一样，他也尝过成功和失望的滋味。重要的是他可以从两者中学习——对我们来说更重要的是他可以把他的经验教训传递下去。
马丁
2003年4月
指数
下载指数与此标题相关的文件。