DDD（Domain Driven Design 领域驱动设计）术语表

DDD（Domain Driven Design 领域驱动设计）领域驱动设计是一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发。

AGGREGATE（聚合）——聚合就是一组相关对象的集合，我们把聚合作为数据修改的单元。
外部对象只能引用聚合中的一个成员，我们把它称为根。在聚合的边界之内应用一组一致的规
则。
分析模式（analysis pattern）——分析模式是用来表示业务建模中的常见构造的概念集合。
它可能只与一个领域有关，也可能跨多个领域[Fowler 1997, p. 8]。
ASSERTION（断言）——断言是对程序在某个时刻的正确状态的声明，它与如何达到这个状
态无关。通常，断言指定了一个操作的结果或者一个设计元素的固定规则。
BOUNDED CONTEXT（限界上下文）——特定模型的限界应用。限界上下文使团队所有成员能
够明确地知道什么必须保持一致，什么必须独立开发。
客户（client）——一个程序元素，它调用正在设计的元素，使用其功能。
内聚（cohesion）——逻辑上的协定和依赖。
命令，也称为修改器命令（command/modifier）——使系统发生改变的操作（例如，设置变
量）。它是一种有意产生副作用的操作。
CONCEPTUAL CONTOUR（概念轮廓）——领域本身的基本一致性，如果它能够在模型中反映
出来的话，则有助于使设计更自然地适应变化。
上下文（context）——一个单词或句子出现的环境，它决定了其含义。参见 BOUNDED CONTEXT。
CONTEXT MAP（上下文图）——项目所涉及的限界上下文以及它们与模型之间的关系的一种
表示。
CORE DOMAIN（核心领域）——模型的独特部分，是用户的核心目标，它使得应用程序与众
不同并且有价值。
声明式设计（declarative design）——一种编程形式，由精确的属性描述对软件进行实际的
控制。它是一种可执行的规格。
深层模型（deep model）——领域专家们最关心的问题以及与这些问题最相关的知识的清晰
表示。深层模型不停留在领域的表层和粗浅的理解上。

设计模式（design pattern）——设计模式是对一些互相交互的对象和类的描述，我们通过定
制这些对象和类来解决特定上下文中的一般设计问题[Gamma et al. 1995, p. 3]。
精炼（distillation）——精炼是把一堆混杂在一起的组件分开的过程，从中提取出最重要的
内容，使得它更有价值，也更有用。在软件设计中，精炼就是对模型中的关键方面进行抽象，或
者是对大系统进行划分，从而把核心领域提取出来。
领域（domain）——知识、影响或活动的范围。
领域专家（domain expert）——软件项目的成员之一，精通的是软件的应用领域而不是软件
开发。并非软件的任何使用者都是领域专家，领域专家需要具备深厚的专业知识。
领域层（domain layer）——在分层架构中负责领域逻辑的那部分设计和实现。领域层是在软
件中用来表示领域模型的地方。
ENTITY（实体）——一种对象，它不是由属性来定义的，而是通过一连串的连续事件和标识
定义的。
FACTORY（工厂）——一种封装机制，把复杂的创建逻辑封装起来，并为客户抽象出所创建
的对象的类型。
函数（function）——一种只计算和返回结果而没有副作用的操作。
不可变的（immutable）——在创建后永远不发生状态改变的一种特性。
隐式概念（implicit concept）——一种为了理解模型和设计的意义而必不可少的概念，但它
从未被提及。
INTENTION-REVEALING INTERFACE（释意接口）——类、方法和其他元素的名称既表达了初始
开发人员创建它们的目的，也反映出了它们将会为客户开发人员带来的价值。
固定规则（invariant）——一种为某些设计元素做出的断言，除了一些特殊的临时情况（例
如，方法执行的中间，或者尚未提交的数据库事务的中间）以外，它必须一直保持为真。
迭代（iteration）——程序反复进行小幅改进的过程。也表示这个过程中的一个步骤。
大型结构（large-scale structure）——一组高层的概念和/或规则，它为整个系统建立了一种
设计模式。它使人们能够从大的角度来讨论和理解系统。
LAYERED ARCHITECTURE（分层架构）——一种用于分离软件系统关注点的技术，它把领域层
与其他层分开。
生命周期（life cycle）——一个对象从创建到删除中间所经历的一个状态序列，通常具有一
些约束，以确保从一种状态变为另一种状态时的完整性。它可能包括ENTITY在不同的系统和
BOUNDED CONTEXT之间的迁移。
模型（model）——一个抽象的系统，描述了领域的所选方面，可用于解决与该领域有关的
问题。
MODEL-DRIVEN DESIGN（模型驱动的设计）——软件元素的某个子集严格对应于模型的元素。
也代表一种合作开发模型和实现以便互相保持一致的过程。

建模范式（modeling paradigm）——一种从领域中提取概念的特殊方式，与工具结合起来使
用，为这些概念创建软件类比。 (例如，面向对象编程和逻辑编程。) REPOSITORY（存储库）——一种把存储、检索和搜索行为封装起来的机制，它类似于一个对
象集合。
职责（responsibility）——执行任务或掌握信息的责任[Wirfs-Brock et al. 2003, p. 3]。 SERVICE（服务）——一种作为接口提供的操作，它在模型中是独立的，没有封装的状态。
副作用（side effect）——由一个操作产生的任何可观测到的状态改变，不管这个操作是有意
的还是无意的（即使是一个有意的更新操作）。
SIDE-EFFECT-FREE FUNCTION（无副作用的函数）——参见[FUNCTION]。 STANDALONE CLASS（孤立的类）——无需引用任何其他对象（系统的基本类型和基础库除
外）就能够理解和测试的类。
无状态（stateless）——设计元素的一种属性，客户在使用任何无状态的操作时，都不需要
关心它的历史。无状态的元素可以使用甚至修改全局信息（即它可以产生副作用），但它不保存
影响其行为的私有状态。
战略设计（strategic design）——一种针对系统整体的建模和设计决策。这样的决策影响整
个项目，而且必须由团队来制定。
柔性设计（supple design）——柔性设计使客户开发人员能够掌握并运用深层模型所蕴含的
潜力来开发出清晰、灵活且健壮的实现，并得到预期结果。同样重要的是，利用这个深层模型，
开发人员可以轻松地实现并调整设计，从而很容易地把他们的新知识加入到设计中。
UBIQUITOUS LANGUAGE（通用语言）——围绕领域模型建立的一种语言，团队所有成员都使
用这种语言把团队的所有活动与软件联系起来。
统一（unification）——模型的内部一致性，使得每个术语都没有歧义且没有规则冲突。
VALUE OBJECT（值对象）——一种描述了某种特征或属性但没有概念标识的对象。
WHOLE VALUE（完整值）——对单一、完整的概念进行建模的对象。