DDD领域驱动设计 - 入门介绍

DDD领域驱动设计

2004年,Eric Evans 出版了《领域驱动设计》一书,提出了针对业务领域建模的方法论和思想 - Domain Driven Design,简称DDD。DDD的核心思想,是从业务视角出发,根据限界上下文划分业务的领域边界,定义领域模型,确定业务边界。在微服务落地时,建立业务领域模型与微服务代码模型的映射,从而保证业务架构与微服务架构的一致性。

DDD是一种处理高度复杂领域的设计思想。DDD提出了一套核心构造块,如聚合、实体、值对象、领域服务、领域工厂、仓储、领域事件等。这些构造块是面向对象领域建模的最佳实践和标准。利用DDD分层架构、六边形、洋葱型等架构,可以达到分离业务复杂度和技术复杂度,让系统具备更强的扩展性和弹性。

DDD战略设计

从业务视角出发,划分业务的领域边界,建立基于通用语言和业务上下文语义边界的限界上下文,构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。领域的战略设计中的领域建模是一个从发散到收敛的过程,通常采用事件风暴工作坊方法。

事件风暴工作坊方法

  1. 针对业务领域,通过用例分析、场景分析和用户旅程分析等方法,尽可能全面地、不遗漏地梳理业务领域,发现这些业务领域中的命令、领域事件、领域对象以及他们的业务行为,并梳理出这些领域对象之间的关系,这是一个发散的过程。

  2. 我们将实现风暴过程中提取的实体、值对象和聚合根等领域对象,从不同的维度进行聚类,形成如聚合和限界上下文等边界,并在限界上下文边界内建立领域模型,这是一个收敛的过程。收敛输出的结果就是领域模型。如图:


    领域的限界上下文和聚合边界

DDD战术设计

从技术视角出发,侧重于领域模型的技术实现,按照领域模型完成微服务的开发和落地。战术设计会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象,这些领域对象以代码的形式映射到微服务中,完成设计和系统落地。

采用DDD设计的缺点

  1. 对开发人员要求相对较高,实现起来会有一定的复杂度

采用DDD设计的优点

  1. DDD是一套完整而系统的设计方法论,规范设计思路和设计过程,形成一套统一的开发设计标准
  2. DDD通过分治策略降低业务和系统建设的复杂度,建立稳定的领域模型,处理高度复杂业务领域的软件开发
  3. DDD领域建模,强调沟通合作,建立团队通用语言
  4. DDD设计有聚合、有边界,容易进行微服务拆分和系统重构

DDD、微服务、中台的关系

DDD是一种架构设计方法论,通过业务边界划分将复杂业务领域简单化,划分出清晰的业务领域和应用边界,从而很容易的实现微服务的架构演进。DDD将子域划分为核心子域、通用子域和支撑子域,目的是识别企业重点领域,有区别地确定战略资源的投入,投入重点自然是核心子域。我们看下DDD视角与中台视角的对应关系,如下图所示:


DDD视角和中台视角的领域分解过程

中台设计偏向于业务架构,形成中台的过程也是业务领域不断细分和能力沉淀的过程,在这个过程中,我们会对同类通用业务能力进行聚合和重构,再根据限界上下文和业务内聚的原则建立领域模型。DDD战略设计最擅长的就是领域建模。在完成中台的领域建模后,领域模型就可以作为微服务设计的输入。限界上下文和领域模型可以作为微服务拆分和设计的边界和依据。如下图所示:

DDD战略设计和战术设计

因此,业务中台和微服务是DDD实战的最佳场景。


DDD、中台和微服务的铁三角关系

更多推荐

DDD(领域驱动设计)从入门到精通

你可能感兴趣的:(DDD领域驱动设计 - 入门介绍)