DDD是一种软件设计思想和方法论,以领域为核心构建软件设计体系,将业务模型抽象成领域模型进行拆解和封装。本文简要介绍DDD的基本概念和常用的分层设计架构,并结合业务场景进行领域驱动设计的实战分析,以加深理解。
领域驱动设计DDD(Domain Driven Design)是一种从系统分析到软件建模的设计思想和方法论,最早在2004年由Eric Evans在著作《Domain-Driven Design –Tackling Complexity in the Heart of Software》中提出相应的概念。其核心思想是以领域为核心驱动力构建软件设计体系,并围绕业务概念抽象出领域模型,通过领域和边界划分将复杂的业务模型抽象化、简单化,最终实现复杂软件应用系统的拆解和封装。DDD不仅可以用于微服务设计,还可以很好地应用于企业中台的设计,也适用于传统的单体应用。
在DDD中分为战略设计和战术设计:
这些年随着软硬件技术的发展,软件设计架构也从最早的单机架构(BS/CS)、到集中式架构,再到如今微服务(MicroServices)分布式架构。
DDD正是一种能够帮助开发人员更好地设计和实现业务领域的模式。通过将业务领域作为核心,DDD可以帮助开发人员更好地理解业务需求,建立正确的业务模型和通用语言,从而更好地划分微服务边界,从而更好地实现微服务的独立性和可维护性。
领域驱动设计DDD中的核心概念如下图所示,包括:
1.3.1 统一语言
DDD中的统一语言(Ubiquitous Language)是一种用于描述业务领域中的概念、规则和流程的语言。它是一种由领域专家、开发人员和用户共同理解的通用语言,而不是一种特定的编程语言或框架。
统一语言贯穿于整个开发过程,从需求分析到设计再到编码。它应该用于描述业务领域中的实体、值对象、聚合、领域服务等概念,同时也要用于描述业务规则、流程和交互。
在统一语言中,应该使用业务领域的术语和词汇,而不是技术术语和词汇。例如,应该使用“客户”而不是“用户”来描述应用程序的客户端,因为“客户”是业务领域中的术语,而“用户”则是技术领域的术语。
统一语言的重要性在于,它能够帮助开发人员更好地理解业务需求和领域模型,同时也能帮助业务专家更好地理解技术和系统实现。它还能够提高代码的可读性和可维护性,因为代码中的术语和词汇能够被业务专家和开发人员共同理解。
1.3.2 领域和子域
在研究和解决业务问题时,DDD会按照一定的业务规则将业务领域进行细分,当领域细分到一定的程度后,DDD会将问题范围限定在特定的边界内,在这个边界内建立领域模型。简言之,领域是业务领域的范围和边界。
领域可以进一步划分为不同的子领域称为子域,每个子域都包含了一些特定的业务规则和功能,它们共同构成了整个业务领域。领域和子域是基于业务需求和功能进行划分,在划分领域和子域时,需要考虑到业务需求的变化和扩展,使得系统能够更好地适应业务需求的变化。
领域和子域的划分也是一种设计上的分层,它能够帮助开发人员更好地理解和组织系统中的代码和模型。在实现时,每个子域都可以被划分成一个或多个限界上下文(Boundary Context),每个限界上下文都包含了一些特定的业务规则和功能,它们共同实现了该子域的功能。
1.3.3 核心域、通用域和支撑域
领域在不断划分的过程中,细分为不同的子域,根据重要性的不同,子域又划分为核心域、通用域和支撑域。
1) 核心域是指业务领域中的核心业务逻辑和模型,它们是领域驱动设计的核心部分。核心域包含领域模型、领域服务、业务规则等,它们是业务领域中最重要、最稳定的部分。
2) 通用域是指业务领域中通用的、可复用的业务逻辑和模型,它们不是核心业务逻辑,但可能在多个核心域中被使用。通用域包含一些通用的业务逻辑、数据校验、安全控制等。
3) 支撑域是指用于支持业务领域中的核心域和通用域的基础设施和工具,包括数据存储、消息传递、分布式系统、自动化测试等。支撑域中不包含业务逻辑和模型,而是聚焦于技术实现和系统监控、管理等方面。
1.3.4 界限上下文
限界上下文是指一个业务领域的边界,它包含了多个子域(Subdomain),每个子域都包含了一些特定的业务规则和功能。限界上下文用来封装通用语言和领域对象,提供上下文环境,保证在领域之内的一些术语、业务相关对象等(通用语言)有一个确切的含义,没有二义性。
限界上下文是一个显式的边界,领域模型便存在于这个边界之内;在边界内,通用语言中的所有术语和词组都有特定的含义,而模型需要准确地反映通用语言。通过限界上下文,开发人员可以更好的组织和管理领域中的不同部分,更好的理解业务需求和领域模型。
1.3.5 实体Entity
实体是拥有唯一标识和状态,且具有生命周期的业务对象。在实体的生命周期内,无论其如何变化,其仍旧是同一个实体。实体的标识和状态可以在业务过程中发生变化,而实体之间的关系也可以随着业务过程的变化而发生变化。
1.3.6 值对象
《实现领域驱动设计》一书中对值对象的定义如下:
通过对象属性值来识别的对象,它将多个相关属性组合为一个概念整体。在DDD中用来描述领域的特定方面,并且是一个没有标识符的对象,叫作值对象。值对象没有唯一标识,没有生命周期,不可修改,当值对象发生改变时只能替换。
值对象将不同的相关属性组成一个整体概念,是一堆不可变属性的集合。
1.3.7 聚合和聚合根
1)聚合和聚合根
DDD中实体和值对象是很基础的领域对象,实体一般对应业务对象、值对象一般是属性集合,但是实体和值对象都是个体化的表现。而聚合是把一些关联性极强、生命周期一致的实体、值对象放到一个聚合里。聚合根(Aggregate Root)是指聚合中的实体,它负责聚合的内聚性和一致性,同时也是聚合的入口点。
聚合有一个聚合根和上下文边界,这个边界根据业务单一职责和高内聚原则,定义了聚合内部应该包含哪些实体和值对象,而聚合之间的边界是松耦合的。按照这种方式设计出来的微服务很自然就是“高内聚、低耦合”的。
2)聚合设计原则
在领域驱动设计中,聚合设计是非常重要的一部分。以下是聚合设计的一些原则
1.3.8 工厂
如果实体或值对象的创建过程非常复杂,可以将其委托给工厂。DDD中工厂是指用于创建领域模型对象的工厂方法,它用于将业务逻辑和实现技术解耦。它是一种设计模式,允许开发人员通过调用工厂方法来创建对象,而不需要直接在代码中实例化对象。
将创建复杂对象和聚合的职责分配给一个单独的对象,该对象本身并不承担领域模型中的职责,但是依然是领域设计的一部分。工厂应该提供一个创建对象的接口,该接口封装了所有创建对象的复杂操作过程,同时,它并不需要客户去引用那个实际被创建的对象。对于聚合来说,我们应该一次性地创建整个聚合,并且确保它的不变条件得到满足。
1.3.9 仓库
仓库(Repository)是一种模式,用于封装数据访问逻辑,提供对数据的持久化和查询。仓库操作的最小单元就是聚合,每个聚合会对应一个仓库。它旨在将数据访问细节与领域模型分离,使领域模型更加独立和可测试。
仓库提供了一种统一的接口,使得领域模型可以与不同的数据存储方式进行交互,同时也提供了一些查询操作。例如,一个客户仓库可以具有存储客户、检索客户等方法。通过调用仓库方法,开发人员可以存储和检索客户对象,同时也可以在存储和检索对象时执行其他的业务逻辑和验证。
1.3.10 领域服务
领域服务(Domain Service)是指跨越多个聚合或子域的逻辑服务,用于处理业务需求和行为。领域服务通常用于执行跨聚合的操作,例如处理业务规则、集成外部系统、执行复杂业务流程等。
需要注意的是,实体和领域服务在实现业务逻辑上不是同级的,当领域中的某些功能,单一实体或者值对象不能实现时,领域服务就会出马,它可以组合聚合内的多个实体或者值对象,实现复杂的业务逻辑。
1.3.11 领域事件
领域事件(Domain Event)是指业务领域中发生的一些事件,通常意味着领域对象状态的改变。领域事件在系统中起到了传递消息、触发其他动作的作用,是解耦领域模型的重要手段之一。在实现时,领域事件可以由领域模型中的实体或服务触发,例如当用户注册成功时,可以触发一个“用户注册成功”的领域事件。领域事件也可以由外部系统或服务触发,例如当第三方支付系统支付成功时,可以触发一个“订单支付成功”的领域事件。
领域事件处理包括:事件构建和发布、事件数据持久化、事件总线、消息中间件、事件接收和处理等。
事件发布方式很多,可以通过应用服务或领域服务发布到事件总线或消息中间件;也可以从事件列表中定时获取增量事件数据发布到消息中间件。
1.3.12 贫血模型和充血模型
1)贫血模型(Anemic Domain Model)
所谓的贫血模型指的是定义领域对象的时候,只有对象的属性信息,没有对象的行为信息。贫血模型强调了业务逻辑和数据之间的分离,将业务逻辑和数据分别放在不同的对象中,导致领域模型变得贫血、不灵活和难以维护。
2)充血模型(Rich Domain Model)
充血模型指的是领域对象既包括属性信息,又包含行为信息。在充血模型中,领域对象包含了业务逻辑、数据和规则,它们被组织在一个聚合根中。
相对而言贫血模型相对简单,模型上只有数据没有行为,针对简单的模型可以快速的完成交付,但是后期的成本较高,并且难以保证事务的一致性和完整性。充血模型则是领域模型模式,实现逻辑上由各自的对象负责,具备事务的一致性和完整性,事务边界也被包含在聚合根中。
在DDD领域中,常见的领域驱动设计架构有以下几种:
1) 分层架构:将领域模型和业务逻辑分离出来,并减少对基础设施和应用层的依赖,从最早三层架构,演化到四层架构、五层架构,包括用户接口层、应用层、领域层和基础设施层。分层架构中,每层只能与位于其下方的层耦合。
2) 六边形架构:也称为端口与适配器。对于每种外界类型,都有一个适配器与之相对应。该架构的定义涉及六个部分,分别是应用程序、域、基础设施、适配器、API和外部系统。六边形架构的核心理念是应用通过端口与外部进行交互。
3) CQRS架构:CQRS架构是一种读写分离的架构设计,系统被分为两个部分:命令端(Command)和查询端(Query)。命令端负责处理写操作(例如修改数据),而查询端则负责处理读操作(例如查询数据)。
4) 事件驱动架构:用于处理事件的生成、发现和处理等任务的软件架构。在这种架构中,领域对象之间通过发布和订阅事件来通信,一个事件通常会引发多个服务的同步,从而引起事件的扩散。
实现DDD的最大好处是第一时间将业务需求构建成领域模型,而不是将其切割为数据和行为,然后再用数据库去实现。DDD具有以下优点:
当然使用DDD需要一定的学习和使用成本,开发人员需要掌握一定的领域建模知识和技能。同时在高并发场景下,由于DDD使用的模型可能会增加一些额外的开销。
DDD的分层架构在不断的优化,在最早的四层架构中(如左上图所示),基础设施层被其它层依赖,处于最核心的位置,但实际上领域层才是依赖的核心。后来采用依赖倒置的设计,优化了传统的四层架构,实现了各层对基础设施层的解耦。四层架构包括:用户接口层、应用层、领域层和基础设施层。
1) 用户接口层:负责展示用户界面和处理用户输入,它通常包含一些前端框架和UI组件;
2) 应用层:负责处理业务逻辑和应用程序的流程,它通常包含一些应用程序服务,例如事务处理、规则验证和流程管理等;
3) 领域层:领域层是领域模型的核心,它负责表示业务领域中的实体、值对象、聚合、领域服务等。领域层通常包含一些领域模型类、领域服务类和领域事件等;
4) 基础设施层:负责提供一些通用服务和功能,例如数据存储、消息传递、日志记录等。基础设施层通常包含一些工具类、库和框架等。
在传统架构中,由于上层应用对数据库的强耦合,很多业务在架构演进中担心更换数据库对应用的影响,因为一旦更换数据库,就可能需要重写大部分代码,这对开发来说是致命的。采用依赖倒置的设计后,应用层通过解耦保持独立的核心业务逻辑,当数据库变更后,只需要更换数据库基础服务即可,对应用的影响降到最低。
六边形架构又称为“端口-适配器”架构,对于每种外界类型,都有一个适配器与之相对应,其核心设计思想是外界通过应用API与内部进行交互。
如图所示的六边形架构中,核心业务逻辑(应用程序和领域模型)与外部资源(包括Web应用、基础设施等)完全隔离,仅通过适配器进行交互。除了核心的领域模型,还包括如下三个层次:
在六边形架构中,一个端口可能对应多个外部系统,不同的外部系统也可能会使用不同的适配器,由适配器负责协议转换。因此在使用时,根据用例来设计应用程序,所有的适配器使用相同的API满足不同的端口访问需求。
CQRS是一种读写分离的架构设计,系统分为两个部分:命令端和查询端,命令端负责处理写操作,而查询端负责处理读操作。在CQRS架构中,写操作和读操作被分离并分布在两个独立的系统中。命令端和查询端之间的数据一致性采用最终一致性的方式处理。这意味着查询端可能会返回不是最新的数据,但系统会确保在一定时间内数据达到一致状态。
除了分离写操作和读操作,CQRS架构还涉及到事件的概念。事件表示命令操作领域中的聚合根状态发生变化后产生的事件。这些事件可以被其他服务订阅,以实现系统的联动。
前面介绍了DDD的基本概念以及主要架构,这些概念很抽象,读起来是一头雾水。下面以“在线书店”为例,探讨下DDD具体落地实践。
在战略设计阶段,主要过程分为业务场景分析、领域建模、划分边界上下文,战略设计是DDD中的核心步骤。
3.1.1 业务场景分析
业务场景分析阶段是对业务的全面梳理,将业务中涉及到的细节展现出来,为后续的领域建模提供足够的业务输入。常见的业务场景分析方法有事件风暴法、四色建模法、用例分析法等,四色建模法相对比较复杂,本文以事件风暴法对“在线书店”业务场景进行分析梳理。
1)场景分析参与方
事件风暴类似于头脑风暴的方法,业务场景的分析讨论参与角色包括领域专家、产品经理、需求分析人员、架构师、项目经理、开发经理和测试经理。参与者要尽可能遍历所有业务细节,列出具体的业务场景、业务规则、业务之间的关联以及热点问题等。
2)业务讨论与梳理
经过事件风暴讨论后,总结出“在线书店”下的典型的业务场景,包括:
分析业务中的事件,寻找业务逻辑和业务规则,比如用户购书流程,从用户注册登录、书籍查询推荐、订单创建和支付等流程进行梳理。下面是按照业务操作对象、事件和命令(动作)形成事件风暴小黑板对整个业务流程进行梳理。
3.1.2 领域建模
在领域建模时,根据场景分析过程中产生的领域对象,找出产生命令的实体,分析实体之间的依赖关系产生聚合,为聚合划定界限上下文,建立领域模型以及模型之间的依赖。根据上图业务场景分析,提取产生这些行为的实体,包括用户、订单、书籍、购物车和系统管理。
完成领域对象分析后,需要构建业务聚合,首先在实体中找到聚合根,根据聚合根的特点,聚合根是一个实体具有全局唯一标识,并且具备生命周期的同时需要专门的模块进行管理。根据这些特征就有了书籍、用户、订单和系统管理这些聚合。
3.1.3 划分边界上下文
获得了整个业务流程中的所有聚合后,需要更具业务语义上下文将具体的聚合划分到对应的上下文中。根据订单和购物车的业务操作行为,订单和购物车共同构成订单域分别管理订单和购物车,用户管理和系统管理共同构成系统和用户管理,因此分为订单域、商品域及系统和用户管理域三个限界上下文。
3.2.1 微服务拆分
通常一个限界上下文拆分为一个微服务,微服务的设计还需要考虑服务的粒度、分层、边界划分、依赖关系和集成关系。因此,在“在线书店”业务场景中,拆分为订单服务、商品服务和系统用户管理服务三个微服务。
3.2.2 领域分层
根据前面介绍的四层分层架构,对领域进行分层设计,包括:用户接口层、应用层、领域层和基础设施层。
3)定义一个领域服务类BookstoreService,它包含一些业务逻辑,例如添加书籍、查找书籍和下架书籍等
4)定义一个领域事件类BookEvent,它代表书籍状态的变化,例如书籍上架、书籍下架等:
5)定义一个应用服务类BookstoreApplicationService,它与用户交互,并调用领域服务类中的方法来实现业务逻辑:
以上是Python实现一个简单的DDD项目示例,它包含了实体、值对象、领域服务、领域事件和应用服务等多个组件。
本文简要介绍了DDD领域驱动设计的核心概念、常用的分层架构,并结合实际业务场景落地DDD设计实现。总而言之,DDD是一种软件设计的思想和方法论,其核心是将业务抽象成领域模型,并以领域为核心驱动力构建软件设计体系,将复杂的业务模型抽象化,非常适合微服务架构下的开发设计。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞6
添加新评论0 条评论