维基百科

领域驱动设计

领域驱动设计（英语：domain-driven design，缩写 DDD）是软件代码的结构及语言（类别名称、类方法、类变量）需符合业务领域（英语：business domain）中的习惯用法。例如处理租赁业务的软件，其类型可以命名为LoanApplication及Customer，其方法可以用AcceptOffer及Withdraw。

领域驱动设计可以将实现对应到持续进化的模型[1]。

领域驱动设计的前提是：

  • 把项目的主要重点放在核心领域（core domain）和领域逻辑
  • 以领域中的模型为基础，进行复杂的设计
  • 让技术人员以及领域专家（英语：Subject-matter expert）合作，以迭代方式来完善特定领域问题的概念模型

该词是由埃里克・埃文斯（Eric Evans）在其同名书中创造。[2]

概念

编辑

模型中有以下概念：

上下文（Context）
情境、脉络、上下文。比如：电子商务系统。
领域（Domain）
知识，影响，或活动。客户使用软件要处理旳问题种类即为软件的领域。
模型（Model）
一类描述域的不同方面并可用于解决相关问题的系统化的抽象。
通用语言（Ubiquitous Language）
一种领域专家使用，为了描述域模型而构造的语言，以减少沟通成本。


战略

编辑

理想情况下，只有一个统一的模型。 但是通常情况下都无法实现，因此在实践中通常分成多个模型。 认识这个事实并遵守它对实践是非常有益的。 策略设计的目的是设计一套原则用于是维护模型完整性，提升领域模型和使用多个模型。

界限上下文（bounded context）

编辑

任何大型项目都有多个模型。 然而，当基于不同模型的代码相结合，软件变得越来越多，不可靠，并且难以理解。 团队成员之间的交流变得越来越难。 模型的使用情境变得越来越不清晰。

因此：需要明确定义模型适用的上下文，并且根据团队组织，应用程序特定部分的使用情况以及代码库和数据库模式等物理表现明确设置边界。 保持模型在这些范围内严格一致，并且不被外部的问题影响。

持续集成（continuous integration）

编辑

当愈多人在相同的有限背景下工作时，模型就愈应该分裂。 团队越大，问题就越大，即使只有三四个人也会遇到严重的问题。 然而，将系统分解为更小的环境最终会失去一个有价值的集成和一致性。

因此：建立一个经常合并所有代码和其他实现工件的过程，用自动化测试快速标记碎片。通过持续地运用统一术语去夯实随着概念在不同人的头脑中的演变而逐渐形成对模型的共同观点。

上下文映射（context map）

编辑

在缺乏全局认识的情况下，个别有界上下文会留下一些问题。 其他模型的背景可能仍然是模糊不清的。 其他团队的人不会意识到上下文的界限，并且会不知不觉地做出模糊边缘或使连接复杂化的变化。 当连接必须在不同的上下文之间进行时，它们往往会相互渗透。

因此：确定项目中正在使用的每个模型并定义其有界的上下文。 这包括非面向对象子系统的隐式模型。 命名每个有界的上下文，并将其命名为通用语言的一部分。 描述模型之间的关联点，确保任何用于共享交流的词语都有清晰明确的含义。 映射现有的情形。

基础

编辑

在领域驱动设计一书中[2]阐述了一些高层次的概念和实践，比如通用语言，这意味着领域模型应该形成领域专家为描述系统需求而提供的共同语言，同样的，这些语言也需要能够被商业用户或赞助商和软件开发商使用。本书专注于将领域层描述为具有多层体系结构的面向对象系统中的常见层次之一。在 DDD 中，有表示，创建和检索域模型的工件：

Entity
一个不由自身属性定义而是由标识线和它的身份定义的对象
例如：大多数航空公司在每次航班上都独特地区分每个座位。每个席位都是在这种情况下的一个实体。不过，西南航空，EasyJet 和瑞安航空并没有区分每个座位；所有的座位都是一样的。在这种情况下，一个席位实际上是一个Value Object
Value Object
只包含元素属性的不可变对象
例如：当人们交换名片时，他们一般不会区分每张独特的名片；他们只关心印在卡片上的信息。在这种情况下，名片是 Value Object
Service
强调与其他对象的关系，只定义了可以为客户做什么，不应该替代 Entity 和 Value Object 的所有行为
Module
一种表达机制，划分代码和概念
Factory
对于那些需要创建特定域对象的方法应该委派给工厂对象，因为这样可以更容易的替换实现
Repository
对于检索特定域对象的方法应该委派给 Repository 对象，因为这样可以很容易地互换替代存储的实现
Aggregate
由 ROOT ENTITY 绑定在一起的对象的集合，也称为聚合根。聚合根通过禁止外部对象保持对其成员的引用来保证在聚合内进行的更改的一致性
例如：驾驶汽车时，不必思考如何让车轮前进，如何点燃引擎等。你只需要正常的使用。在这种情况下，汽车是其他几个对象的集合，并作为所有其他系统的聚合根
Domain Event
一个域对象定义了一个事件。域事件是域专家所关心的事件

局限

编辑

为了帮助保证模型能作为一个单纯并有用的语言结构，团队通常必须在领域模型中实现大量的隔离和封装。因此，基于领域驱动设计的系统可能会花费相对较高的成本。虽然域驱动设计提供了许多技术优势，如可维护性，但 Microsoft 建议仅将它应用于复杂领域中，在这些复杂领域中，通过模型和语言处理能够在复杂信息中提供交流便利性的，并且能够该领域达成共识。[3]

与其它概念的关系

编辑

工具

编辑

采用 DDD 并不依赖于特定的工具。然而，也有许多开源的工具和框架可用，包括：

参见

编辑

参考文献

编辑
  1. ^ Domain driven design, [2017-11-03], （原始内容存档于2021-04-12） .
  2. ^ 2.0 2.1 Evans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. 2004 [August 12, 2012]. ISBN 978-032-112521-7. （原始内容存档于2019-05-13）. .
  3. ^ Microsoft Application Architecture Guide, 2nd Edition, [2017-12-25], （原始内容存档于2019-01-30） 

外部链接

编辑
检索自“https://zh.wikipedia.org/w/index.php?title=領域驅動設計&oldid=82921429”