DDD 极简教程

概述

DDD(Domain-Driven Design 领域驱动设计)是由Eric Evans最先提出,目的是对软件所涉及到的领域进行建模,以应对系统规模过大时引起的软件复杂性的问题。整个过程大概是这样的,开发团队和领域专家一起通过 通用语言(Ubiquitous Language)去理解和消化领域知识,从领域知识中提取和划分为一个一个的子领域(核心子域,通用子域,支撑子域),并在子领域上建立模型,再重复以上步骤,这样周而复始,构建出一套符合当前领域的模型。

DDD概述

这里需要注意几点:

  • 通用语言是一个很泛的概念,它作为一种沟通工具,在开发团队内部,开发团队与领域专家之间使用。它包含了自然语言、文档和图表(不一定是标准的UML图,只要能表达出领域知识的都可以)等内容。对通用语言中名词,动词的使用需要认真考量,因为这些名词和动词会作为后面模型的指导命名。
  • 通用语言中定义的术语在一个 限界上下文(bounded context)中不能存在二义性。同一个事物在不同的限界上下文中因为所关注的侧重点不同,所以所表达出的概念是不同的,但在同一个限界上下文中应该表示的是一个概念。比如用户在微信中的聊天场景,朋友圈以及支付场景中所有表达的概念就应该是不同的,聊天场景关注的是用户间的聊天内容,而支付场景关注的是用户的账户余额。
  • 一个子域可以包含多个限界上下文。
  • 模型(Entity,值对象,Service,Aggregate root)是存在于限界上下文中的。

分层架构

DDD中将系统分为UI层,应用层,领域层以及基础设施层。

分层架构

上图中,应用层是很薄的一层,因为它只负责接收UI层传来的参数和路由到对应的领域模型,它不负责处理具体的业务逻辑。系统的业务逻辑放在了领域层中,所以,领域层在系统架构中占据了很大的面积。

在层级结构中,上层模块调用下层模块提供的服务,这里就会存在一种依赖关系,Rebort C. Martin提出的依赖倒置原则大致是如下:

上层模块不应该依赖于下层模块,两者都应该依赖于抽象;
抽象不应该依赖于实现,实现应该依赖于抽象;

这是一个面向接口编程的思想,抽象说的是抽象类或接口,实现就是具体实现了这些抽象的实现类。翻译成白话文是这样的,上下层之间应该通过接口来通讯,接口定义的位置就决定了上下层的依赖关系是否倒置。比如Application层和Domain层进行通讯,接口与接口的实现类都定义在Domain层中,这是正常的面向接口编程,不存在倒置关系。而Domain层和基础设施层进行通讯时,原本是Domain层去依赖基础设施层,如果我们将接口定义在Domain层,而实现类定义在基础设施层,那么,基础设施层就将依赖Domain层,这就是“倒置”这个词的来由。实际上,我们在做这样分层架构设计时,都是将接口定义在Domain层的。

DDD元素

在使用DDD设计系统时,主要包括Entity,Value Object,Service,Aggregate,Repository,Factory,Domain Event,Moudle等元素。

ddd元素

在建模时,Entity可以用来代表一个事物。既然Entity是用来代表一个事物的,那么它就应该有一个唯一值来标识这个事物,同时,他还能记录这个事物状态的变化。比如:Id为5的Person对象,它的名字是张三,过两天,他将自己的名字改为李四。但是,这个人(Id=5)还是这个人(Id=5),只是他名字的状态以及发生了变化,而这个变化后的状态被Person这个Entity记录了下来。

Value Object是用来描述事物的某一方面的特征,所以它是一个无状态的,且是一个没有标识符的对象,这是和Entity的本质区别。拿订单来说,一张订单在系统中应该有一个唯一的标识,且具有状态,所以订单是一个Entity对象,而这张订单共¥100元,则是描述了这个订单的总额特征,¥100元可以用值对象表示为{100,¥},及金额和币种的组合。{100,¥}在任何限界上下文中都描述的是¥100元,是因为他们比较的是里面的内容(金额和币种),而上面的张三在修了名后,还是原来的那个人,是因为它比较的是唯一标示ID的值。

Aggregate是一组相关对象的集合,它作为数据修改的基本单元,为数据修改提供了一个边界。每个聚合都有一个根和一个边界,根也是一个实体,聚合边界以外的对象只能通过根对聚合内部元素操作。聚合将一组相关的对象内聚到一起,从而将系统的复杂程度降低。

repository用来存储聚合,相当于每一个聚合都应该有一个仓库实例。Entity和Value Object都应该具有行为,而有些行为从语义上讲,不适合放到这两个对象中,所以就单独抽象了一个Service对象,用来存放这些行为。Factory是用来生成聚合的,当生成一个聚合的步骤过于复杂时,可以将其生成过程放在工厂中。

推荐阅读更多精彩内容

  • 前言 至少30年以前,一些软件设计人员就已经意识到领域建模和设计的重要性,并形成一种思潮,Eric Evans将其...
    Vgecanshang阅读 1,343评论 3 7
  • 2004年,当Eric Evans的那本《领域驱动设计——软件核心复杂性应对之道》(后文简称《领域驱动设计》)出版...
    无知者云阅读 6,215评论 6 98
  • 引言 在讨论DDD分层架构的模式之前,我们先一起回顾一下DDD和分层架构的相关知识。 DDD DDD(Domain...
    _张晓龙_阅读 38,075评论 8 123
  • 领域驱动设计的概念 ​大家都知道软件开发不是一蹴而就的事情,我们不可能在不了解产品(或行业领域)的前提下进行软件开...
    jebysun阅读 531评论 0 3
  • 心安之处,便是归处! 缘至缘离 如丝去缕 逍遥而去 亘古不变 我心不变 斯亿万年 等相守等邂逅等归客等路人 听你上...
    夏添_阅读 20评论 0 0