《领域驱动设计：软件核心复杂性应对之道》Eric Evans 2

《领域驱动设计：软件核心复杂性应对之道》Eric Evans 2016年版本

封面

序言：

关注领域，关注核心领域，关注领域驱动的设计，关注模型驱动的开发。

对于业务本身就很复杂的程序开发，你是无法回避这种复杂性，你所能做的只有控制这种复杂性。

本书描述并建立了领域驱动建模艺术的词汇库。提供了一个参考框架。

在领域建模过程中不应该将概念和实现割裂开来。建模人员不仅要与业务人员沟通顺畅，还要与开发人员一块写代码。

领域模型的最大价值在于它提供了一种通用语言，这种语言是将领域专家和技术人员联系在一起的纽带。

领域模型设计驱动开发，并不是“先建模，后实现”的思维模式，而是随着时间迭代演进模型和实践。

在领域建模过程中不应该与实现割裂开来。

概念与实现密不可分的主要原因在于，领域模型的最大价值是它提供了一种通用语言，这种语言是将领域专家和技术人员联系在一起的纽带。

Eric的经验告诉我们，真正强大的领域模型是随着时间演进的，即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。

---- Martin Fowler.

前言：

业务人员，开发人员，以及公共语言的领域模型。这几个之间并行工作且持续关联。

成功的项目都有一个共同的特征，那就是都有一个丰富的领域模型，这个模型在迭代设计的过程中不断演变，而且成为项目不可分割的一部分。

面对复杂领域的软件开发团队可以利用这个框架来系统性地应用领域驱动设计。

成功的项目，不仅仅要交付有用的软件，而且还有后续的目标：交付能够满足组织后续需求，可以不断演进的复杂软件。

很多系统的技术使用方面值得商榷，但是很多系统失败在业务逻辑上，前面版本过早地变得僵化，成为一个维护代价十分高昂的遗留系统。

在领域模型的基础上，反复精华，在代码上也要体现这些精华。

复杂性的挑战：

在大多数软件项目中，主要的焦点应该是领域和领域逻辑。

复杂的领域设计应该基于模型。

领域驱动设计是一种思维方式，它旨在加速哪些必须处理复杂领域的软件项目的开发。它有一套完整的设计实践，技术和原则。

领域驱动设计与敏捷开发过程相结合，互相增强。

本书遵循两个开发实践：

1. 迭代开发。它是敏捷开发的基础。

2. 开发人员和领域专家具有密切的关系。领域驱动设计的实质就是吸收消化大量知识，最后产生一个反映深层次领域知识并聚焦于关键概念的模型。领域专家精通领域知识，开发人员构建模型和软件。迭代式开发，贯穿于项目的整个生命周期。

第一部分：“运用领域模型” 提出领域驱动开发的基本目标，这些目标是后面几部分讨论的实践的驱动因素。

第一章 消化知识

1.1. 有效建模的要素

软件开发中的应用所需知识的广度令人望而生畏，庞大而复杂的信息也可能超乎想象。

领域模型正是解决此类信息超载问题的工具。模型这种知识形式对知识进行了选择性的简化和有意的结构化。适当的模型可以使人理解信息的意义，并专注于问题。

建模更像是制作电影 -- 出于某种目的而概括地反映现实。就如同电影制片人讲述股市或者阐明观点时，他们会选择素材，并以一种特殊的方式将他们呈现给观众，建模领域人员也会依据模型的作用来选择具体的模型。

模型在领域驱动设计中的作用：

1.模型和设计的核心互相影响。

2.模型是团队所有成员使用的通用语言的中枢。

3.模型是浓缩的知识。

有效建模的要素：

(1). 模型和实现的绑定。

(2). 建立了一种基于模型的语言。

(3). 开发一个蕴含丰富知识的模型。对象具有行为和强制性规则。模型并不仅仅是一种数据模型，它还是解决复杂问题不可或缺的部分。模型包含各种类型的知识。

(4). 提炼模型。

(5). 头脑风暴和试验。语言和草图，再加上头脑风暴活动，将我们的讨论变成 “模拟实验室”，在这些讨论中可以掩饰，尝试和判断上百种变化。

1.2. 知识消化

金融分析师要消化理解的内容是数字。

高效的领域建模人员是知识的消化者。

信息的原始资料来自领域专家头脑中的知识，现有系统的用户，以及技术团队以前在相关遗留系统或同领域的其他项目中积累的经验。

建模不仅仅在于寻找实体和值对象时，还需要寻找业务规则和业务活动。

在一个需要团队成员持续学习的真实项目中，要想建立实用且清晰的模型则要求团队成员既精通领域知识，也要精通建模技术。

1.3. 持续学习

1.4 知识丰富的设计

1.5 深层模型

==================================================

第二章 交流与语言的使用

领域模型可成为软件项目通用语言的核心。模型不仅仅局限于UML(统一建模语言)图。

通用语言的词汇包括类和主要操作的名称。

模型之间的关系成为所有语言都具有的组合规则。词和短语的意义反映了模型的语义。

开发人员应该使用基于模型的语言来描述系统中的工作，任务和功能。而且领域专家应该使用这种语言来讨论需求，开发计划和特性。

将模型作为语言的支柱。确保团队在内部所有的交流中以及代码中坚持使用这种语言，在画图，写东西，特别是讲话时也要使用这种语言。

只有一个模型在起作用，那么不同模型的共存，如何防止模型分裂。

讨论系统时要结合模型。使用模型元素及其交互来大声描述场景，并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话，然后将这些新的想法应用到图和代码中。

如果连经验丰富的领域专家都不能理解模型，那么模型一定出了什么问题。

在敏捷过程中，需求是随着项目的前进而演变的，因为几乎不存在现在的知识可以允许说明一个应用程序。

文档和图：

UML图，主要是以类图和对象交互图为主。

UML图一方面过于细致，一方面过于遗漏。

UML图无法传达模型的两个最重要的方面，一个方面是模型所表示的概念的意义，另一方面是对象应该做哪些事情。

设计的重要细节应该在代码中体现。良好的实现应该是透明的，清楚地展示其背后的模型。

文档作为代码和口头交流的补充。

将代码作为设计文档的局限性，它可能会把读代码的人淹没在细节中。

文档不应该再重复表示代码已经表达出的内容。

当编程语言无法直接了当地实现概念时，文档可以澄清设计意图。我们应该把书面文档作为代码和口头讨论的补充。

为了消除各种差异，需要使用诸如声明式设计这样的方法，在这类方法中，程序元素用途的陈述决定了它在程序中的实际行为。

解释性模型：

解释性模型

第三章 绑定模型和实现

领域驱动设计要求模型不仅能够指导早期的分析工作，还应该成为设计的基础。

如果整个程序设计或其核心部分没有与领域模型相对应，那么这个模型就没有价值的，软件的正确性也值得怀疑。同时，模型和设计功能之间过于复杂的对应关系也是难以理解的，在实际项目中，当设计改变时也无法维护这种关系。若分析和设计之间差生严重分歧，那么再分析和 设计活动中所获得的知识就无法彼此共享。

Model-driven design(模型驱动设计)不再将分析模型和设计开发分离开，而是寻求一种能够满足这两个方面的单一模型。

为了使Model-Driven Design发挥作用，一定要在可控范围内严格保证模型和设计之间的一致性。

模型>>范式>>设计

任何参与建模的技术人员，不管在项目中的主要职责是什么，都必须花时间了解代码。

任何修改代码的人员则必须学会用代码来表达模型。

每一个开发人员都必须不同程度地参与模型讨论并且与领域专家保持联系。

参与不同工作的人都必须有意识地通过Ubiquitous language与接触代码的人即使交换关于模型的思想。

第二部分：“模型驱动设计的构建块” 将面向对象领域建模中的一些核心的最佳实践提炼为一组基本的构建块。使用标准模式可以为公共语言贡献术语，使得所有团队成员可以使用这些术语来讨论模型和设计决策。

第四章 分离领域

第五章 软件中所表示的模型

第六章 领域对象的生命周期

第七章 使用语言：一个扩展的示例

这一部分是讨论一些能够保持模型和实现之间互相协调并提高效率的设计决策。

第三部分：“通过重构来加深理解”讨论如何将构建块配置为实用的模型，从而实现其价值。

探索本身是永无止境的，但这并不意味着它是随机的。

第四部分：“战略设计” 讨论在复杂系统，大型组织以及外部系统和遗留系统的交互中出现的复杂情况。

这一部分讨论了作为一个整体应用于系统的3条原则：上下文，提炼和大型结构。