域驱动开发

维基百科,自由的百科全书
跳转至: 导航搜索

领域驱动设计(英语:Domain-driven design,缩写 DDD)是一种通过将实现连接到持续进化的模型[1]来满足复杂需求的软件开发方法。 领域驱动设计的前提是:

  • 把项目的主要重点放在核心域(CORE DOMAIN)和域逻辑
  • 把复杂的设计放在有界域(BOUNDED CONTEXT) 的模型上
  • 发起一个创造性的合作之间的技术和 域界专家 以迭代地完善的概念模式,解决特定领域的问题

该词是由 埃里克*埃文斯 (Eric Evans) 在其同名书中创造。[2]

概念[编辑]

模型中有以下概念:

上下文
词或句子出现的位置。
一类知识 (ontology),影响,或活动。软件使用的场景。
模型
一类描述域的不同方面并可用于解决相关问题的系统化的抽象。
统一术语(UBIQUITOUS LANGUAGE)
一种团队成员使用,为了描述域模型而构造的语言。

战略[编辑]

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

界限上下文(BOUNDED CONTEXT)[编辑]

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

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

持续集成(CONTIO)[编辑]

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

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

上下文地图(CONTEXT MAP)[编辑]

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

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

基础[编辑]

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

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


局限[编辑]

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

与其它概念的关系[编辑]

工具[编辑]

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

参见[编辑]

参考文献[编辑]

外部链接[编辑]