DDD领域驱动分层架构设计及业务场景实践.docx

《DDD领域驱动分层架构设计及业务场景实践.docx》由会员分享，可在线阅读，更多相关《DDD领域驱动分层架构设计及业务场景实践.docx（26页珍藏版）》请在优知文库上搜索。

1、1.DDD领域驱动设计基本概念理解1.1 什么是DDD领域驱动设计？领域驱动设计DDD(DomainDrivenDesign)是一种从系统分析到软件建模的设计思想和方法论，最早在2004年由EricEvans在著作Domain-DrivenDesign-TacklingComplexityintheHeartofSoftware中提出相应的概念.其核心思想是以领域为核心驱动力构建软件设计体系，并围绕业务概念抽象出领域模型，通过领域和边界划分将豆杂的业务模型抽象化、简单化，最终实现巨杂软件应用系统的拆解和封装.DDD不仅可以用于微服务设计，还可以很好地应用于企业中台的设计，也适用于传统的单体应用

2、。在DDD中分为战略设计和战术设计：战略设计：主要从业务视角出发，建立业务领域模型、划分领域边界、建立通用语言的限界上下文。在战略设计中，需要对领域进行全面的了解和分析，探究业务的规则和本质，以及领域未来的趋势发展和可能变化.战术设计：从技术视角出发，侧重于领域模型的技术实现完成软件开发和落地，包括：实体、值对象、聚合、工厂、仓而、领域服务、领域事件等代码逻娼的设计和实现。战术设计关注的是领域中的具体情境和场景,需要针对具体的问题进行具体的分析和设计，以满足业务需求.1.2 DDD领域驱动设计和微服务关系这些年随着软硬件技术的发展，软件设计架构也从最早的单机架构(BS/CS)、到集中式架构，再

3、到如今微服务(MicroServices)分布式架构.单机架构：采用面向过程的设计方法，系统包括应用客户端层和数据库层，整个系统围绕数据库驱动设计和开发.集中式架构：采用面向对象的设计方法，经典的三层架构包括业务接入层、业务逻辑层和数据访问层.这种集中式架构容易在某一层变得腌肿，另外受限于集中式的限制，可扩展性差，架构上不熨活。分布式微服务架构：微服务架构将应用程序拆分为一系列相互协作的微服务，每个微服务负责一个特定的业务领域或业务功能，从而实现应用之间的解耦，同时解决单体应用扩展性和灵活性问题.在微服务架构中，每个微服务都是独立的，可以使用不同的编程语言、数据存储和框架，这使得每个微服务可以

4、独立地演进和部署.DDD的概念最早在2004年就提出来之后一直不温不火直到微服务的概念出现.也可以说DDD的流行和微服务的发展有一定的关系.微服务的兴起使得越来越多的开发人员开始关注如何将应用程序划分成一系列相互协作的循服务，并且每个微服务需要实现自己的业务逻辑.在这个过程中，开发人员发现他们需要一种更好的方式来划分业务领域边界，建立正确的业务模型和通用语言,以便更好地实现微服务的独立性和可维护性.DDD正是一种能够帮助开发人员更好地设计和实现业务领域的模式,通过将业务领域作为核心，DDD可以帮助开发人员更好地理解业务需求，建立正确的业务模型和通用语言，从而更好地划分微服务边界，从而更好地实现

5、微服务的独立性和可维护性.1.3 DDD领域驱动设计中核心概念领域驱动设计DDD中的核心概念如下图所示，包括：战略设计：包括领域/子域、统一语言、限界上下文等概念战术设计：使用这些模式来捕获和传递领域中的概念、关系、规则代表领域的概念：如实体、值对敏、领域服务、领域事件等用于管理对演的生命周期：如聚合、工厂、费源库等用于集成或跟踪:领域事件、事件溯源等1.3.1 统一语言DDD中的统一语言(Ubiquitous1.anguage)是一种用于描述业务领域中的概念、规则和流程的语言,它是一种由领域专家、开发人员和用户共同理解的通用语言,而不是一种特定的编程语言或框架.统一语言贯穿于整个开发过程，从

6、需求分析到设计再到编码.它应该用于描述业务领域中的实体、值对象、聚合、领域服务等概念，同时也要用于描述业务规则、流程和交互.在统一语言中，应该使用业务领域的术语和词汇，而不是技术术语和词汇。例如，应该使用“客户而不是用户”来描述应用程序的客户端，因为客户”是业务领域中的术语，而“用户”则是技术领域的术语.统一语言的重要性在于，它能第帮助开发人员更好地理解业务需求和领域模型，同时也能帮助业务专家更好地理解技术和系统实现.它还能够提高代码的可读性和可维护性，因为代码中的术语和词汇能够技业务专家和开发人员共同理解.1.3.2 领域和子域在研究和解决业务问题时，DDD会按照一定的业务规则将业务领域进行

7、细分，当领域细分到一定的程度后，DDD会将问题范围限定在特定的边界内，在这个边界内建立领域模型.简言之，领域是业务领域的范围和边界.领域可以进一步划分为不同的子领域称为子域，每个子域都包含了一些特定的业务规则和功能，它们共同构成了整个业务领域.领域和子域是基于业务需求和功能进行划分，在划分领域和子域时，需要考虑到业务需求的变化和扩展，使得系统能够更好地适应业务需求的变化.领域和子域的划分也是一种设计上的分屉,它能够帮助开发人员更好地理解和组织系统中的代码和模型。在实现时，每个子域都可以被划分成一个或多个限界上下文(BoundaryContext),每个限界上下文都包含了一些特定的业务规则和功能

8、，它们共同实现了该子域的功能.1.3.3 核心域、通用域和支撑域领域在不断划分的过程中，细分为不同的子域，根据电要性的不同，子域又划分为核心域、通用域和支厚域.1）核心域是指业务领域中的核心业务遗帽和模型，它们是领域驱动设计的核心部分.核心域包含领域模型、领域服务、业务规则等，它们是业务领域中最重要,最稳定的部分.2）通用域是指业务领域中通用的、可复用的业务逻辑和模型，它们不是核心业务逻辑，但可能在多个核心域中被使用。通用域包含一些通用的业务逻担、数据校验、安全控制等.3）充理域是指用于支持业务领域中的核心域和通用域的感础设施和工具，包括数据存玮、消息传递、分布式系统、自动化测试等。支撑域中不

9、包含业务逻期和模型，而是聚焦于技术实现和系统监控、管理等方面.1.3.4 限界上下文限界上下文是指一个业务领域的边界，它包含了多个子域（Subdomain）,每个子域都包含了一些特定的业务规则和功能.限界上下文用来封装通用语言和领域对象，提供上下文环境，保证在领域之内的一些术语、业务相关对象等（通用语三）有一个确切的含义，没有二义性。限界上下文是一个显式的边界，领域模型便存在于这个边界之内；在边界内，通用语言中的所有术语和词组都有特定的含义，而模型需要准确地反映通用语言.通过限界上下文，开发人员可以更好的组织和管理领域中的不同部分，更好的理解业务需求和领域模型.领域、子域和限界上下文的关系如下

10、图所示:1.3.5 实体Entity实体是拥有唯一标识和状态，且具有生命周期的业务对象.在实体的生命周期内，无论其如何变化，其仍旧是同一个实体.实体的标识和状态可以在业务过程中发生变化，而实体之间的关系也可以随若业务过程的变化而发生变化.实体的业名形态：在领域模型中实体是多个届性、操作或行为的戮体,实体的属性描述实体的状态比如客户的姓名、年龄等；实体的行为指实体可以执行的操作，比如创建、更新等.实体和值对象是组成领域模型的基础单元。实体的代码形态：在代码模型中，实体表现为实体类，这个类包含了实体的属性和方法，通过这些方法实现实体自身的业务遗掘。实体的运行形态：实体是以DO（领域对象）的形式存在

11、，每个实体对象都有一个唯一的ID,这个ID在实体的整个生命周期内无论实体对象怎么变化都具有唯一性.实体的数据库形态QDD先构建领域模型，再针对业务场景构建实体对象和行为,最后将实体对象映射到数据持久化对象.在领域模型映射到数据模型时，一个实体可能对应。个、1个或者多个数据库持久化对象.1.3.6 值对象实现领域驱动设计一书中对值对象的定义如下：通过对象,属性值来识别的对象，它将多个相关属性组合为一个概念整体.在DDD中用来描述领域的特定方面，并且是一个没有标识符的对象，叫作值对象。值对象没有唯一标识，没有生命周期，不可修改，当值对象发生改变时只能替换.值对余将不同的相关属性组成一个整体概念，是

12、一堆不可变质性的集合。值对象的业务形态：值对象是若干不可修改的属性集合，只有数据初始化操作和有限不涉及数据修改的行为，基本不包含业务逻娼。值对象在逻辑上依然是实体属性的一部分.值对象的代码形态：如果值对象是单一属性例如字符串、整型、枚举等，则亘接定义为实体类的属性；如果值对源是属性集合，则把它设计为Class类，包含多个属性.值对象的运行形态：值对象嵌入到实体中,有两种不同的数据格式分别是属性嵌入的方式和序列化大对象的方式，比如JSON字段1.3.7 聚合和聚合根1)聚合和聚合根DDD中实体和值对象是很基础的领域对象,实体一般对应业务对象、值对象一般是属性集合，但是实体和值对象都是个体化的表现

13、.而聚合是把一些关联性极强、生命周期一致的实体、值对象放到一个聚合里,聚合根(AggregateRoot)是指聚合中的实体，它负责聚合的内聚性和一致性，同时也是聚合的入口点.聚合有一个聚合根和上下文边界，这个边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象，而聚合之间的边界是松融合的.按照这种方式设计出来的微服务很自然就是高内聚、低楷合的。2）聚合设计原则在领域驱动设计中，聚合设计是非常生要的一部分.以下是聚合设计的一些原则：保持完整性：聚合中包含一组相互关联的实体和值对象，它们被视为一个整体.聚合的边界应该明确，以保持其完整性。保持一致性：聚合内数据强一致性，而聚合之

14、间数据最终一致性.聚合中的实体和值对象在业务规则和均束下保持一致,如果一个聚合违反了业务规则或约束，那么它就不是一个一致的聚合.保持小型聚合：鬃合尽可能小，只包含必要的实体和值对象.小型聚合可以降低由于业务过大导致聚合里构，有助于提高系统的可维护性和可扩展性.避免聚合根以外的实体：聚合根以外的实体应该尽可能避免，因为它们增加了系统的豆杂性和藕合度.如果必须使用这些实体，应该确保它们与聚合根之间的关系是一致的.避免跨聚合引用：如果一个实体或值对象需要引用另一个聚合中的实体或值对源.通过关联外部聚合根ID的方式引用，而不是直接对象引用的方式。这样可以保持聚合的独立性和可维护性.1.3.8 工厂如果

15、实体或值对象的创建过程非常豆杂，可以将其委托给工厂.DDD中工厂是指用于创建领域模型对象的工厂方法，它用于将业名逻辑和实现技术解褐.它是一种设计模式，允许开发人员通过调用工厂方法来创建对象，而不需要直接在代码中实例化对象，将创建复杂对象和聚合的职责分配给一个单独的对象，该对象本身并不承担领域模型中的职责，但是依然是领域设计的一部分.工厂应该提供一个创建对彖的接口，该接口封装了所有创建对象的复杂操作过程，同时，它并不需要客户去引用那个实际被创建的对象.对于聚合来说，我们应该一次性地创建整个聚合，并且确保它的不变条件得到满足.1.3.9 仓库仓库(Repository)是一种模式,用于封装数据访问

16、逻辑，提供对数据的持久化和查询.仓库操作的最小单元就是聚合，每个聚合会对IS一个仓库.它旨在将数据访问细节与领域模型分曲,使领域模型更加独立和可测试.仓库提供了一种统一的接口，使得领域模型可以与不同的数据存储方式进行交互.同时也提供了一些直询操作.例如，一个客户仓库可以具有存储客户、检索客户等方法.通过调用仓库方法，开发人员可以存储和检索客户对象，同时也可以在存储和检索对象时执行其他的业务逻箱和验证.1.3.10 领域服务领域服务(DomainService)是指跨越多个聚合或子域的逻辑服务,用于处理业务需求和行为.领域服务通常用于执行跆聚合的操作，例如处理业务规则、集成外部系统、执行弟杂业务流程等.需要注意的是，实体和领域服务在实现业务逻辑上不是同级的，当领域中的某些功能，单