CN113326027B - 一种领域驱动设计战术建模方法 - Google Patents

Abstract

本发明公开了一种领域驱动设计战术建模方法，属于领域驱动设计实践技术领域。本发明公开了一种领域驱动设计战术建模方法，包括：战术模式选择、建模结果验证以及实现建模结果。所述战术模式选择部分包括挑选实体、值对象、领域服务、领域事件、聚合、模块、资源库、工厂以及确认上述模式的重要特征属性；所述建模结果验证部分包括对战术模式属性规范性、约束条件以及模式间关系的验证；所述建模结果实现部分包括战术模式的实现技术方案和技术细节。本发明支持高效简单地使用领域驱动设计战术建模模式，能有效校验建模结果的标准性与规范性，还能将建模结果进行具体实现，为战术建模流程提供了一套可靠的流程。

Description

一种领域驱动设计战术建模方法

技术领域

本发明涉及领域驱动设计实践技术领域，具体为一种领域驱动设计战术建模方法。

背景技术

领域驱动设计是一种针对复杂业务流程的软件设计方法，它可以帮助架构师和软件开发人员提炼业务流程和构建复杂软件系统。近年来，越来越多的团队将领域驱动设计应用到大型分布式系统的设计与实现中。与传统的系统设计方式相比，领域驱动设计更加聚焦领域中的业务流程而非系统操作的数据，强调领域模型的重要性。领域驱动设计遵循关注点分离的原则，对领域对象进行了明确的策略和职责划分，可以将现实业务映射到领域对象上，为领域专家与开发人员搭建沟通的桥梁。通过领域驱动设计，开发团队和领域专家深入交谈，对业务了解更加准确，领域专家借助领域驱动设计的方法与开发团队进行沟通，可以更好地对领域进行建模，并对建模的领域对象进行快速迭代修改，同时将修改同步到实现层次上，更加适应快速迭代的敏捷软件开发节奏。

然而，作为领域驱动设计的核心内容，战术建模的应用却存在诸多问题与挑战。其一，战术建模模式的实践过程仍缺少标准且统一的规范，使得实践者无法准确地使用这些模式建模业务流程；其二，战术建模实践过程所缺少的规范，也使得开发人员和架构设计人员在使用这些建模模式时具有不同的理解，从而带来了一系列项目团队沟通问题；其三，现有的大多数战术建模仅仅停留在设计阶段，无法很好地进行落地实践。

导致战术建模难以实践的原因有很多。第一，战术建模这一概念本身就很复杂，战术建模层次包含的概念知识十分丰富，且每一种模式都很复杂，没有大量的实战经验基本无法理解，学习战术建模的成本很高；第二，由于一线开发人员开发水平、经验差距较大，对领域驱动设计的理解也不够深入，同一开发团队也往往很难让建模结果保持标准和统一；第三，在实际应用战术建模时也没有具体的实现技术方案进行指导，导致战术建模难以规范化、标准化地应用到实际建模设计与实践落地当中。因此，人们需要一种规范化、标准化的领域驱动设计战术建模方法。

发明内容

本发明的目的在于提供一种领域驱动设计战术建模方法，以解决上述背景技术中提出的问题。

为了解决上述技术问题，本发明提供如下技术方案：一种领域驱动设计战术建模方法，该方法包括以下步骤：

S1、战术模式选择，选择合适的战术模式对战术建模过程中出现的对象进行建模表示；

S2、建模结果验证，根据战术建模的统一规则和规范化标准，对战术建模的结果进行验证和修改；

S3、实现建模结果，根据不同的战术模式实现技术方案，挑选合适的技术方案对战术建模结果进行实现；

所述战术模式选择中包括的战术模式有实体、值对象、领域服务、领域事件、聚合、模块、资源库、工厂以及这些战术模式的重要特征属性；

所述建模结果验证包括对战术模式重要特征属性规范性、约束条件以及模式间关系的验证；

所述实现建模结果包括战术模式的实现技术方案和技术细节；

其中，对战术模式的重要特征属性规范性的验证为检验战术模式的属性名和属性值的合法性；

对战术模式约束条件的验证为检验战术模式必要属性是否缺失、属性值范围以及其他约束条件；

对模式间关系的验证为检验了战术模式间关联关系的合理性，防止战术模式间的非法连接；

对战术模式的实现技术方案和细节，包括对所有战术模式和这些战术模式属性的实现和约束方案。

根据上述技术方案，在步骤S1的战术模式选择过程中包括以下步骤：

S1-1、先对需要进行战术建模的领域进行业务分析，与相关领域专家一同进行战略建模，划分限界上下文，明确各边界特定职责，为战术建模做前期准备；

S1-2、将某个限界上下文中的领域模型分解成数据字典和行为模式，把需要考虑个性特征，或者需要与其他对象区分的对象建模为实体；

S1-3、将用来度量和描述事物的对象建模成值对象；

S1-4、将领域中不是实体或值对象职责的某个操作或转换过程建模成领域服务；

S1-5、将在领域中发生的领域专家所关心事件建模成领域事件，用来维护事件一致性；

S1-6、将负责组织内聚类，解耦无关类的容器建模成模块；

S1-7、将聚集了相关实体和值对象到一致性边界内的容器建模成聚合，并选出某个实体作为聚合根代表此聚合；

S1-8、将负责存取操作聚合实例或提供聚合实例访问接口的对象建模成资源库；

S1-9、将具有创建复杂对象和聚合职责的单独对象建模成工厂。

根据上述技术方案，在步骤S1-1中，战略建模需要与领域专家沟通，建立通用的业务语言即通用语言，明确业务的知识体系与核心诉求，从而发现要在模型中使用的主要的领域概念，然后进行划分领域和子域，明确领域边界，分析不同边界的特定职责，划分业务最小集；将不同的业务职责分配到不同的限界上下文中，并明确限界上下文映射关系；

在步骤S1-2中，实体是一个具有个性特征的对象，实体对象可以与其他对象区别开来，实体应该是唯一的，因为需要区别于其他实体，所以需要借助唯一标识进行区分，实体只根据唯一标识进行区分，而不是实体的属性，实体除了具有唯一性以外，在其生命周期中还具有可变性；

在步骤S1-3中，值对象可以度量和描述事物，值对象的创建、测试、使用、优化和维护都很方便，值对象是不变对象，不需要任何标识，还应该尽量避免像实体对象一样的复杂性，值对象无法继续正确表达其状态时，度量和描述会进行改变，可以用另一个值对象直接替换，值对象的相等性通过比较两个对象的类型和属性来决定，值对象的方法必须是一个无副作用函数，即只用于产生输出，而不会修改值对象状态的方法；

在步骤S1-4中，领域服务以单独的接口或实现类的形式存在，负责领域中的某个操作或转换过程，领域服务关注实体和值对象职责之外的业务，在单个原子操作中处理多个领域对象，并且命名要与通用语言一致，此外，领域服务是无状态的；

在步骤S1-5中，领域事件捕获发生在领域中的领域专家所关心的事情，领域专家所关心的事情指在与专家进行讨论时，领域专家强调“当…时”的时候，将其建模成领域事件，维护事件的一致性时，也需要用到领域事件，该事件往往是需要发布到外部系统的，比如外部限界上下文，使用领域事件可以在不打破聚合原则(一个事务中只允许修改一个聚合)的前提下，保证事件的一致性，另外，还可以让远程依赖系统与本地系统保持一致，领域事件中包含记录事件发生的时间的属性，还包含标识事件发送方的属性，方便准确把握事件的来源，当跨限界上下文或系统发布事件时，还需要使用唯一标识来将领域事件与其他对象进行区分；

在步骤S1-6中，模块将不同的内聚的类放在不同的模块中进行解耦，模块是一个命名的容器，用于存放内聚的类，并可以对不在同一个模块的类解耦；

在步骤S1-7中，聚合将实体和值对象聚类到一致性边界内，聚合不仅仅是聚集了一些共享父类、密切关联的对象，更加重要的是其更关注内部的不变条件和整体的一致性边界，从外部来看，聚合是一个原子性整体，聚合的所有操作都是事务的，聚合中需要选出一个实体充当聚合根，来充当聚合与外部交互的媒介；

在步骤S1-8中，资源库可以存储聚合实例，之后再通过资源库获取相同的聚合实例；资源库原则上只为聚合提供，但有时也可以为实体提供，资源库还包含一些与业务逻辑无关的额外行为，如计算总数的函数或特殊化查询方法。

在步骤S1-9中，工厂是一种具有创建复杂对象和聚合职责的单独对象，该对象并不承担领域模型中的职责，但是依然是领域设计的一部分，工厂方法不承担任何业务逻辑，只有创建逻辑。

根据上述技术方案，所述建模结果验证包括以下步骤：

S2-1、对战术模式的属性名和属性值的合法性进行验证；

S2-2、对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证；

S2-3、对战术模式之间关联关系的合理性进行验证，防止了战术模式间的非法连接。

根据上述技术方案，在步骤S2-1中对战术模式的属性名和属性值合法性进行验证，包括以下步骤：

S2-1-1、保证实体的命名和唯一标识的命名符合英文语法规范，保证唯一标识命名和唯一标识具体值中不含有非法字符；

S2-1-2、保证值对象的命名符合英文文法规范；

S2-1-3、保证领域服务的命名符合英文语法规范，并与通用语言保持一致；

S2-1-4、保证领域事件的命名符合英文语法规范且能表示过去发生的含义，保证唯一标识命名和唯一标识具体值中不含有非法字符，保证事件发生时间属性是合法时间；

S2-1-5、保证模块的命名符合英文语法规范，并符合具体实现层面的规范(如Java包命名规范)；

S2-1-6、保证聚合的命名符合英文语法规范，保证根实体为聚合内部的实体；

S2-1-7、保证资源库的命名符合英文语法规范，并能反映出对象种类为资源库；

S2-1-8、保证工厂的命名符合英文语法规范，并能反映出对象种类为工厂；

根据上述技术方案，在步骤S2-2中对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证，包括以下步骤：

S2-2-1、保证实体必须含有且只能含有一个唯一标识属性，且对唯一标识取值范围进行规定，保证符合业务场景，保证实体是可以变化的；

S2-2-2、保证值对象不可改变，可以使用其他值对象进行替换，保证值对象中的方法都是无副作用行为；

S2-2-3、保证领域服务是无状态的；

S2-2-4、保证领域事件必须含有事件发生时间、事件发送方以及唯一标识属性，保证发生时间为过去时间，保证事件发送方对象不为空且属于业务领域范围内的对象，保证唯一标识取值范围合业务场景，保证领域对象不可变化，因为事件是过去已经发生的既定事实；

S2-2-5、保证聚合内所有对象状态保持一致，且作为整体时所有操作都是原子性的，保证根实体不为空且为聚合内的实体对象；

S2-2-6、保证资源库的额外行为不包含业务逻辑，资源库连接的对象必须是合法的聚合或实体；

根据上述技术方案，在步骤S2-3中对战术模式之间关联关系的合理性进行验证，防止战术模式间的非法连接，包括以下步骤：

S2-3-1、保证领域服务的输入必须连接至少一个实体或值对象；

S2-3-2、保证领域服务的输出必须连接至少一个值对象；

S2-3-3、保证领域事件的事件发送方属性必须与一个对象连接；

S2-3-4、保证模块必须至少连接一个对象；

S2-3-5、保证聚合必须包含一个根实体，且表示与外界连接时，只能连接聚合的根实体；

S2-3-6、保证资源库必须且只能和聚合根或实体连接；

根据上述技术方案，所述实现建模结果包括以下步骤：

S3-1、为各个战术模式的重要属性实现选择技术方案；

S3-2、为各个战术模式的整体实现选择技术方案，并注意技术细节；

根据上述技术方案，在步骤3-1中为各个战术模式的重要属性实现选择技术方案，包括以下步骤：

S3-1-1、为实体生成具有可读性的唯一标识；可以选择由用户提供一个或多个初始值作为程序输入，并保证唯一；或由应用程序生成唯一标识；或使用持久化机制生成唯一标识；或由另一个限界上下文提供唯一标识；

S3-1-2、确定唯一标识的生成时间；可以选择在对象创建时就生成唯一标识(及早生成)；或在对象持久化时生成唯一标识；

S3-1-3、使用操作命令的英文完成时态为领域事件命名；这种方式可以确保与通用语言保持一致，并表达事件已经发生的状态；

S3-1-4、为领域事件对象定义记录发生时间的方法；

S3-1-5、为资源库添加全局接口，方便客户端进行访问，确保拥有资源库的聚合可以很方便地存取实例；

根据上述技术方案，在步骤S3-2中为各个战术模式的整体实现选择技术方案，并注意技术细节，包括以下步骤：

S3-2-1、保持值对象不变性，确保除了初始化方法，其他任何方法都不能对该对象的属性状态进行修改；

S3-2-2、确保值对象的可比较性，值对象的相等性通过比较两个对象的类型和属性来决定；

S3-2-3、选择存储值对象集合的技术方案；可以选择将多个值对象序列化到单个列中，该方式是将整个集合序列化成某种形式的文本，然后将此文本保存到单个数据库列中；或者使用数据库实体保存多个值对象，使用数据库实体保存多个值对象，涉及到委派主键；或者使用联合表保存多个值对象，该方式简单地将值对象集合元素保存到一个单独的数据库表中，然后在该表中维护一个到领域实体所对应表的外键关联，该外键指向数据库实体的唯一标识；

S3-2-4、选择实现领域服务的技术方案；可以选择定义接口来实现领域服务，适合于领域服务有多种不同特点的实现类的情况；或者直接定义实现类，适合领域服务只有一个实现类的情况；

S3-2-5、保持领域事件的不变性，只允许领域事件对象构造函数全状态初始化，不提供修改属性的方法；

S3-2-6、保证订阅方在事件发生前订阅事件；将事件发布动作和订阅方注册行为放到应用服务中，确保订阅发生在事件发生之前；

S3-2-7、保证领域模型和事件存储的一致性；可以选择让领域模型和消息设施共享持久化存储，使模型修改和事件提交发生在同一个本地事务中；或者让全局事务控制领域模型和消息设施，保证最终的一致性；

S3-2-8、选择转发领域事件的方式；可以选择通过RESTful资源的形式发布，一个发布方发布的事件可以供多个消费方消费；或者选择以消息中间件形式发布；

S3-2-9、同层模块出现耦合时，杜绝循环依赖；

S3-2-10、为资源库存储的聚合提供下一个带有顺序性的唯一标识。

本行业技术人员应理解，除非特意声明，以下所提“领域”均代表当前语义中的问题空间，而非代表广义上的行业概念。进一步可以理解的是，以下所提“某领域”代表具体的某个领域而非限定在当前语义。

本文使用的术语“战术模式”是战术建模中常用的表达业务问题的一种方式，包含领域中的抽象概念、关系和约束规则，并将领域模型和通用语言中的概念映射到实现技术中。

本文使用的术语“领域模型”是对领域中概念或对象的可视化表示，专注于领域本身，可以用来分析业务，发掘重要的业务领域概念，并建立业务领域概念之间的关系。

本文使用的术语“领域专家”是拥有特定领域的丰富知识与实践经验的从业人员，在建模过程中起主导作用。

本文使用的术语“战略建模”是从宏观角度对领域业务进行建模的建模方法，强调领域内的业务特性。战略建模可以划分出业务的边界、组织团队结构以及系统架构，为后续的战术建模划定限界上下文。

本文使用的术语“限界上下文”是一种概念性边界，限定了领域模型的工作范围。每一个模型概念和其中的属性与操作，在它所属的边界之内，都有特定的含义，通过之前约定的通用语言，参与建模的团队成员应该可以明确领域模型的具体含义。

本文使用的术语“通用语言”是将团队沟通与软件实现紧密联系到一起的一种基于模型的语言，在应用通用语言进行领域建模时，领域专家和开发人员可以更好地讨论需求、制定开发计划和描述系统特性。

本文使用的术语“领域”是某个业务关注的范围界定，可以进一步划分为核心域、通用域和支撑域。

本文使用的术语“上下文映射”是帮助项目团队成员理解不同上下文间关系的文档。通过上下文映射，可以从宏观上看到每个上下文之间的关系，能够更好地指导后续的程序设计。

本文使用的术语“唯一标识”是用来标识对象唯一性的一种不可重复的属性。

本文使用的术语“无副作用函数”是一种只用于产生输出，而不会修改对象状态的方法函数。

本文使用的术语“委派主键”是在存储值对象时，将其所关联的实体的主键作为多个值对象的主键，在领域层值对象依然是值对象，到了数据库存储时，可以当作其已经变成了“实体”。

本文使用的术语“RESTful”是一种软件构建风格，允许客户端发出以统一资源标识符访问和操作网络资源的请求，而与预先定义好的无状态操作集一致化。

与现有技术相比，本发明所达到的有益效果是：

1、本发明支持高效简单地使用领域驱动设计战术建模模式，能有效校验建模结果的标准性与规范性，还能将建模结果进行具体实现，为战术建模流程提供了一套可靠的流程，通过该方法，可以有效联系战术建模结果与具体实现，帮助架构师和软件开发人员提炼业务流程和构建复杂软件系统；

2、本发明为战术建模模式的实践过程提供了标准且统一的规范，使得实践者可以准确地使用这些模式建模业务流程，减少了开发人员和架构设计人员两方项目团队的沟通问题，并且能够很好地进行落地实践，同时也降低了学习成本。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明一种领域驱动设计战术建模方法的流程图；

图2是本发明一种领域驱动设计战术建模方法实施例一中的第一阶段战术模式选择阶段的流程图；

图3是本发明一种领域驱动设计战术建模方法实施例二中的第二阶段建模结果验证阶段的流程图；

图4是本发明一种领域驱动设计战术建模方法实施例二中的第三阶段实现建模结果阶段的流程图；

图5是本发明一种领域驱动设计战术建模方法实施例三中使用的流程图；

图6是本发明一种领域驱动设计战术建模方法实施例中的最终建模结果图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图1-6，本发明提供技术方案：一种领域驱动设计战术建模方法，该方法包括以下步骤：

S1、战术模式选择，选择合适的战术模式对战术建模过程中出现的对象进行建模表示；

S2、建模结果验证，根据战术建模的统一规则和规范化标准，对战术建模的结果进行验证和修改；

S3、实现建模结果，根据不同的战术模式实现技术方案，挑选合适的技术方案对战术建模结果进行实现；

所述战术模式选择中包括的战术模式有实体、值对象、领域服务、领域事件、聚合、模块、资源库、工厂以及这些战术模式的重要特征属性；

所述建模结果验证包括对战术模式重要特征属性规范性、约束条件以及模式间关系的验证；

所述实现建模结果包括战术模式的实现技术方案和技术细节；

其中，对战术模式的重要特征属性规范性的验证为检验战术模式的属性名和属性值的合法性；

对战术模式约束条件的验证为检验战术模式必要属性是否缺失、属性值范围以及其他约束条件；

对模式间关系的验证为检验了战术模式间关联关系的合理性，防止战术模式间的非法连接；

对战术模式的实现技术方案和细节，包括对所有战术模式和这些战术模式属性的实现和约束方案。

在步骤S1的战术模式选择过程中包括以下步骤：

S1-1、先对需要进行战术建模的领域进行业务分析，与相关领域专家一同进行战略建模，划分限界上下文，明确各边界特定职责，为战术建模做前期准备；

S1-2、将某个限界上下文中的领域模型分解成数据字典和行为模式，把需要考虑个性特征，或者需要与其他对象区分的对象建模为实体；

S1-3、将用来度量和描述事物的对象建模成值对象；

S1-4、将领域中不是实体或值对象职责的某个操作或转换过程建模成领域服务；

S1-5、将在领域中发生的领域专家所关心事件建模成领域事件，用来维护事件一致性；

S1-6、将负责组织内聚类，解耦无关类的容器建模成模块；

S1-7、将聚集了相关实体和值对象到一致性边界内的容器建模成聚合，并选出某个实体作为聚合根代表此聚合；

S1-8、将负责存取操作聚合实例或提供聚合实例访问接口的对象建模成资源库；

S1-9、将具有创建复杂对象和聚合职责的单独对象建模成工厂。

在步骤S1-1中，战略建模需要与领域专家沟通，建立通用的业务语言即通用语言，明确业务的知识体系与核心诉求，从而发现要在模型中使用的主要的领域概念，然后进行划分领域和子域，明确领域边界，分析不同边界的特定职责，划分业务最小集；将不同的业务职责分配到不同的限界上下文中，并明确限界上下文映射关系；

在步骤S1-2中，实体是一个具有个性特征的对象，实体只根据唯一标识进行区分，而不是实体的属性，实体除了具有唯一性以外，在其生命周期中还具有可变性；

在步骤S1-3中，值对象可以度量和描述事物，值对象是不变对象，不需要任何标识，还应该尽量避免像实体对象一样的复杂性，值对象无法继续正确表达其状态时，度量和描述会进行改变，可以用另一个值对象直接替换，值对象的相等性通过比较两个对象的类型和属性来决定，值对象的方法必须是一个无副作用函数，即只用于产生输出，而不会修改值对象状态的方法；

在步骤S1-4中，领域服务以单独的接口或实现类的形式存在，负责领域中的某个操作或转换过程，领域服务关注实体和值对象职责之外的业务，在单个原子操作中处理多个领域对象，并且命名要与通用语言一致，此外，领域服务是无状态的；

在步骤S1-5中，领域事件捕获发生在领域中的领域专家所关心的事情，领域专家所关心的事情指在与专家进行讨论时，领域专家强调“当…时”的时候，将其建模成领域事件，领域事件中包含记录事件发生的时间的属性，还包含标识事件发送方的属性，方便准确把握事件的来源，当跨限界上下文或系统发布事件时，还需要使用唯一标识来将领域事件与其他对象进行区分；

在步骤S1-6中，模块将不同的内聚的类放在不同的模块中进行解耦，模块是一个命名的容器，用于存放内聚的类，并可以对不在同一个模块的类解耦；

在步骤S1-7中，聚合将实体和值对象聚类到一致性边界内，聚合不仅仅是聚集了一些共享父类、密切关联的对象，更加重要的是其更关注内部的不变条件和整体的一致性边界，从外部来看，聚合是一个原子性整体，聚合的所有操作都是事务的，聚合中需要选出一个实体充当聚合根，来充当聚合与外部交互的媒介；

在步骤S1-8中，资源库可以存储聚合实例，之后再通过资源库获取相同的聚合实例；

在步骤S1-9中，工厂是一种具有创建复杂对象和聚合职责的单独对象，该对象并不承担领域模型中的职责，但是依然是领域设计的一部分，工厂方法不承担任何业务逻辑，只有创建逻辑。

所述建模结果验证包括以下步骤：

S2-1、对战术模式的属性名和属性值的合法性进行验证；

S2-2、对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证；

S2-3、对战术模式之间关联关系的合理性进行验证，防止了战术模式间的非法连接。

在步骤S2-1中对战术模式的属性名和属性值合法性进行验证，包括以下步骤：

S2-1-1、保证实体的命名和唯一标识的命名符合英文语法规范，保证唯一标识命名和唯一标识具体值中不含有非法字符；

S2-1-2、保证值对象的命名符合英文文法规范；

S2-1-3、保证领域服务的命名符合英文语法规范，并与通用语言保持一致；

S2-1-4、保证领域事件的命名符合英文语法规范且能表示过去发生的含义，保证唯一标识命名和唯一标识具体值中不含有非法字符，保证事件发生时间属性是合法时间；

S2-1-5、保证模块的命名符合英文语法规范，并符合具体实现层面的规范；

S2-1-6、保证聚合的命名符合英文语法规范，保证根实体为聚合内部的实体；

S2-1-7、保证资源库的命名符合英文语法规范，并能反映出对象种类为资源库；

S2-1-8、保证工厂的命名符合英文语法规范，并能反映出对象种类为工厂；

在步骤S2-2中对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证，包括以下步骤：

S2-2-1、保证实体必须含有且只能含有一个唯一标识属性，且对唯一标识取值范围进行规定，保证符合业务场景，保证实体是可以变化的；

S2-2-2、保证值对象不可改变，可以使用其他值对象进行替换，保证值对象中的方法都是无副作用行为；

S2-2-3、保证领域服务是无状态的；

S2-2-4、保证领域事件必须含有事件发生时间、事件发送方以及唯一标识属性，保证发生时间为过去时间，保证事件发送方对象不为空且属于业务领域范围内的对象，保证唯一标识取值范围合业务场景，保证领域对象不可变化；

S2-2-5、保证聚合内所有对象状态保持一致，且作为整体时所有操作都是原子性的，保证根实体不为空且为聚合内的实体对象；

S2-2-6、保证资源库的额外行为不包含业务逻辑，资源库连接的对象必须是合法的聚合或实体；

在步骤S2-3中对战术模式之间关联关系的合理性进行验证，防止战术模式间的非法连接，包括以下步骤：

S2-3-1、保证领域服务的输入必须连接至少一个实体或值对象；

S2-3-2、保证领域服务的输出必须连接至少一个值对象；

S2-3-3、保证领域事件的事件发送方属性必须与一个对象连接；

S2-3-4、保证模块必须至少连接一个对象；

S2-3-5、保证聚合必须包含一个根实体，且表示与外界连接时，只能连接聚合的根实体；

S2-3-6、保证资源库必须且只能和聚合根或实体连接；

所述实现建模结果包括以下步骤：

S3-1、为各个战术模式的重要属性实现选择技术方案；

S3-2、为各个战术模式的整体实现选择技术方案，并注意技术细节；

在步骤3-1中为各个战术模式的重要属性实现选择技术方案，包括以下步骤：

S3-1-1、为实体生成具有可读性的唯一标识；

S3-1-2、确定唯一标识的生成时间；

S3-1-3、使用操作命令的英文完成时态为领域事件命名；

S3-1-4、为领域事件对象定义记录发生时间的方法；

S3-1-5、为资源库添加全局接口，方便客户端进行访问，确保拥有资源库的聚合可以很方便地存取实例；

在步骤S3-2中为各个战术模式的整体实现选择技术方案，并注意技术细节，包括以下步骤：

S3-2-1、保持值对象不变性，确保除了初始化方法，其他任何方法都不能对该对象的属性状态进行修改；

S3-2-2、确保值对象的可比较性，值对象的相等性通过比较两个对象的类型和属性来决定；

S3-2-3、选择存储值对象集合的技术方案；

S3-2-4、选择实现领域服务的技术方案；

S3-2-5、保持领域事件的不变性，只允许领域事件对象构造函数全状态初始化，不提供修改属性的方法；

S3-2-6、保证订阅方在事件发生前订阅事件；

S3-2-7、保证领域模型和事件存储的一致性；

S3-2-8、选择转发领域事件的方式；

S3-2-9、同层模块出现耦合时，杜绝循环依赖；

S3-2-10、为资源库存储的聚合提供下一个带有顺序性的唯一标识。

在本实施例中：

战术建模开始时，首先进行战术模式选择根据业务中对象的特点以及实体、值对象、领域服务、领域事件、聚合、模块、资源库、工厂这些战术模式的重要特征属性，将对象与战术模式一一对应起来，使用战术模式对对象进行刻画；使用战术模式进行战术建模后，根据战术建模规则要求，对建模结果的属性规范性、约束条件以及模式间关系进行验证；最后，使用技术方案对建模结果进行实现转化，将战术建模结果与具体实现有效连接起来，帮助架构师和软件开发人员提炼业务流程和构建复杂软件系统。

参阅图1所述，本发明实施例提出了一种领域驱动设计战术建模方法，实施例一

该方法分析了复杂业务领域，并使用战术模式对业务对象和场景进行建模，具体地，包括如下步骤：

步骤S100，如图2所示，选定某个限界上下文后，选择合适的战术模式对业务对象进行建模，具体包括以下步骤：

步骤S101，针对划分好的某个限界上下文，对其进行分析，主要将上下文中重要的业务对象进行抽象，方便后续对对象的建模操作；

步骤S102，对于需要表达唯一特征的对象，将其建模为实体，并赋予唯一标识用来和其他实体对象进行区分，追踪该实体对象的变化；

步骤S103，对于用来度量和描述事物的对象，将其建模为值对象，保证该值对象仅包含必要的属性和无副作用函数；

步骤S104，对于业务领域中既不属于实体也不属于值对象的操作或转换过程，将其建模为领域服务对象，并以通用语言进行命名；

步骤S105，对于领域中发生的重要事件，特别是领域专家额外关注的事件，将其建模为领域事件对象，需要维护一个事件的一致性时，也可以将整个事件建模为领域事件对象；

步骤S106，将一些具有共享父类，密切关联的实体或值对象聚类到同一个一致性边界内，形成聚合，保证整个聚合中的对象都保持一致，并选出某个实体作为该聚合的代表，负责与外部进行交互；

步骤S107，为聚合或者某些实体对象提供资源库，资源库负责存取聚合或实体实例，并通过一些与业务逻辑无关的行为，提高对实例对象操作的效率；

步骤S108，针对复杂的对象，为其提供工厂对象负责创建操作，复杂对象在创建时往往包含许多逻辑，但这些创建中的逻辑不属于任何对象的职责，需要将这些逻辑组合封装在工厂对象里，承担创建复杂对象的职责。

实施例二

参阅图3所述，本发明实施例提出的领域驱动设计战术建模方法能对战术建模结果进行验证，验证规则符合领域驱动设计战术建模领域的最前沿研究成果和规范，并根据验证的结果给出对模型的修改意见，具体地，包括如下步骤：

步骤S200，如图3所示，对建模结果进行验证，具体包括以下步骤：

步骤S201，对建模结果中战术模式对象的属性名和属性值合法性进行验证，保证实体、唯一标识、值对象、领域服务、领域事件、模块、聚合、资源库以及工厂的命名符合英文语法规范，保证唯一标识命名和唯一标识具体值中不含有非法字符，保证领域服务的命名与通用语言保持一致，保证领域事件的命名能表示领域事件是过去发生的，保证事件发生时间属性是合法时间，保证聚合根实体为聚合内部的实体，保证资源库和工厂的命名能反映出对象种类为资源库；

步骤S202，对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证，保证实体必须含有且只能含有一个唯一标识属性，且对唯一标识取值范围进行规定，保证符合业务场景，保证实体是可以变化的，保证值对象不可改变，可以使用其他值对象进行替换，保证值对象中的方法都是无副作用行为，保证领域服务是无状态的，保证领域事件必须含有事件发生时间、事件发送方以及唯一标识属性，保证发生时间为过去时间，保证事件发送方对象不为空且属于业务领域范围内的对象，保证唯一标识取值范围合业务场景，保证领域对象不可变化，因为事件是过去已经发生的既定事实，保证聚合内所有对象状态保持一致，且作为整体时所有操作都是原子性的，保证根实体不为空且为聚合内的实体对象，保证资源库的额外行为不包含业务逻辑，资源库连接的对象必须是合法的聚合或实体；

步骤S203，对战术模式之间关联关系的合理性进行验证，防止了战术模式间的非法连接，保证领域服务的输入必须连接至少一个实体或值对象，保证领域服务的输出必须连接至少一个值对象，保证领域事件的事件发送方属性必须与一个对象连接，保证模块必须至少连接一个对象，保证聚合必须包含一个根实体，且表示与外界连接时，只能连接聚合的根实体，保证资源库必须且只能和聚合根或实体连接；

步骤S204，根据验证结果对模型进行修改，根据验证结果反映出的不符合规范的建模结果部分，依照战术模式的规范和约束要求，进行相应的修改，直至符合战术模式要求，并再次进行验证；

参阅图4所述，本发明实施例提出的领域驱动设计战术建模方法能对通过验证的战术建模结果进行实现指导，实现方案符合战术建模要求，经过实践验证，能够帮助战术建模人员快速落地建模结果，建立起模型与实现之间的联系，具体地，包括如下步骤：

步骤S300，如图4所示，为建模结果的实现选择实现方案和技术细节，具体包括以下步骤：

步骤S301，将各个战术模式依据关联程度按模块组织起来，方便后续选择技术方案，将内聚的类聚合到一起，并对不相关的类进行解耦，对模块的组织要符合具体实现层面的规范(如Java包命名规范、C++的命名空间命名规范等)；

步骤S302，为各个战术模式的重要属性实现选择技术方案，为实体生成具有可读性的唯一标识，由用户提供一个或多个初始值作为程序输入，并保证唯一，或由应用程序自动生成唯一标识，或使用持久化机制生成唯一标识，或由另一个限界上下文提供唯一标识。确定唯一标识的生成时间可以选择在对象创建时就生成唯一标识(及早生成)，或在对象持久化时生成唯一标识。使用操作命令的英文完成时态为领域事件命名，这种方式可以确保与通用语言保持一致，并表达事件已经发生的状态。为领域事件对象定义记录发生时间的方法。为资源库添加全局接口，方便客户端进行访问，确保拥有资源库的聚合可以很方便地存取实例；

步骤S303，为各个战术模式的整体实现选择技术方案，并注意技术细节，保证值对象不变性，确保除了初始化方法，其他任何方法都不能对该对象的属性状态进行修改。保证值对象的可比较性，值对象的相等性通过比较两个对象的类型和属性来决定，选择存储值对象集合的技术方案，可以选择将多个值对象序列化到单个列中，该方式是将整个集合序列化成某种形式的文本，然后将此文本保存到单个数据库列中，或者使用数据库实体保存多个值对象，使用数据库实体保存多个值对象，涉及到委派主键，或者使用联合表保存多个值对象，该方式简单地将值对象集合元素保存到一个单独的数据库表中，然后在该表中维护一个到领域实体所对应表的外键关联，该外键指向数据库实体的唯一标识，选择实现领域服务的技术方案，可以选择定义接口来实现领域服务，适合于领域服务有多种不同特点的实现类的情况，或者直接定义实现类，适合领域服务只有一个实现类的情况。保持领域事件的不变性，只允许领域事件对象构造函数全状态初始化，不提供修改属性的方法。保证订阅方在事件发生前订阅事件。将事件发布动作和订阅方注册行为放到应用服务中，确保订阅发生在事件发生之前。保证领域模型和事件存储的一致性，可以选择让领域模型和消息设施共享持久化存储，使模型修改和事件提交发生在同一个本地事务中，或者让全局事务控制领域模型和消息设施，保证最终的一致性。选择转发领域事件的方式，可以选择通过RESTful资源的形式发布，一个发布方发布的事件可以供多个消费方消费，或者选择以消息中间件形式发布。同层模块出现耦合时，杜绝循环依赖。为资源库存储的聚合提供下一个带有顺序性的唯一标识；

实施例三

根据上述原理，对用户身份认证子领域进行战术建模，使用了本发明提出的战术建模方法，建模流程如图5所示，具体地，建模流程步骤如下：

使用英文单词对业务中对象进行建模，英文名称与业务对象对应关系如下：

Person代表“成员”，RegistrationInvitation代表“注册邀请”，Role代表“角色”，Group代表“组”，ContactInformation代表“联系信息”，Enablement代表“授权”，GroupMember代表“组成员”，UserPasswordChanged代表“用户密码已修改”，PersonNameChanged代表“成员名称已修改”，UserRegistered代表“用户已注册”，TenantActivated代表“租户已激活”，User代表“用户”，Tenant代表“租户”；

选择合适的战术模式对业务对象进行建模。将Person、RegistrationInvitation、Role、Group建模为实体，并对这些实体对象的唯一标识、含有的函数方法进行命名，并规定属性类型；

将ContactInformation、Enablement、GroupMember建模为值对象，并为这些值对象的属性和函数方法进行命名，并规定属性类型；

将UserPasswordChanged、PersonNameChanged、UserRegistered、TenantActivated建模为领域事件，并对这些领域事件对象的唯一标识、含有的函数方法、事件发生时间进行命名，并规定属性类型；

划分聚合，以聚合根User代表一个聚合，该聚合包括Person、RegistrationInvitation、UserPasswordChanged、ContactInformation、Enablement以及UserRegistered类；

划分聚合，以聚合根Tenant代表一个聚合，该聚合包括RegistrationInvitation和TenantActivated类；

划分聚合，以聚合根Role代表一个聚合，该聚合包括Role类；

划分聚合，以聚合根Group代表一个聚合，该聚合包括Group、GroupMember类；

为Person、Tenant、Role和Group提供资源库对象；

对建模结果中的对象属性名和属性值的合法性进行验证，验证Person、RegistrationInvitation、Role、Group的唯一标识属性命名和具体值中不含有非法字符，且只能含有一个唯一标识属性，对唯一标识取值范围进行规定，保证符合业务场景；

验证ContactInformation、Enablement、GroupMember不可改变，可以使用其他值对象进行替换，方法都是无副作用行为；

验证UserPasswordChanged、PersonNameChanged、UserRegistered、TenantActivated的唯一标识属性命名和具体值中不含有非法字符，命名能表示其是过去发生的，事件发生时间属性是合法过去时间，事件发送方对象不为空且属于业务领域范围内的对象，唯一标识取值范围合业务场景；

验证User、Tenant、Group以及Role聚合内所有对象状态保持一致，且作为整体时所有操作都是原子性的，根实体不为空且为聚合内的实体对象，聚合必须包含一个根实体，且表示与外界连接时，只能连接聚合的根实体；

验证所有资源库的命名能反映出对象种类为资源库，且只能和聚合根或实体连接；

对所有验证失败的建模结果部分进行修改，直至通过所有验证；

为建模结果的实现选择合适的技术方案，并确定技术细节。使用持久化设施为Person、RegistrationInvitation、Role、Group提供唯一标识，并确保尽早生成；保证ContactInformation、Enablement、GroupMember的可比较性，重写比较函数，通过比较两个对象的类型和属性来决定，对于与实体关联的值对象集合，采用将整个集合序列化成某种形式的文本，然后将此文本保存到单个实体的数据库列中；确认UserPasswordChanged、PersonNameChanged、UserRegistered、TenantActivated都是以操作命令的英文完成时态命名，并与通用语言保持一致，并表达事件已经发生的状态，保持领域事件的不变性，只允许领域事件对象构造函数全状态初始化，不提供修改属性的方法。

最终建模结果如图6所示。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种领域驱动设计战术建模方法，其特征在于：该方法包括以下步骤：

S1、战术模式选择，选择合适的战术模式对战术建模过程中出现的对象进行建模表示；

S2、建模结果验证，根据战术建模的统一规则和规范化标准，对战术建模的结果进行验证和修改；

S3、实现建模结果，根据不同的战术模式实现技术方案，挑选合适的技术方案对战术建模结果进行实现；

所述战术模式选择中包括的战术模式有实体、值对象、领域服务、领域事件、聚合、模块、资源库、工厂以及这些战术模式的重要特征属性；

所述建模结果验证包括对战术模式重要特征属性规范性、约束条件以及模式间关系的验证；

所述实现建模结果包括战术模式的实现技术方案和技术细节；

其中，对战术模式的重要特征属性规范性的验证为检验战术模式的属性名和属性值的合法性；

对战术模式约束条件的验证为检验战术模式必要属性是否缺失、属性值范围以及其他约束条件；

对模式间关系的验证为检验了战术模式间关联关系的合理性，防止战术模式间的非法连接；

对战术模式的实现技术方案和细节，包括对所有战术模式和这些战术模式属性的实现和约束方案；

在步骤S1的战术模式选择过程中包括以下步骤：

S1-1、先对需要进行战术建模的领域进行业务分析，与相关领域专家一同进行战略建模，划分限界上下文，明确各边界特定职责，为战术建模做前期准备；

S1-2、将某个限界上下文中的领域模型分解成数据字典和行为模式，把需要考虑个性特征，或者需要与其他对象区分的对象建模为实体；

S1-3、将用来度量和描述事物的对象建模成值对象；

S1-4、将领域中不是实体或值对象职责的某个操作或转换过程建模成领域服务；

S1-5、将在领域中发生的领域专家所关心事件建模成领域事件，用来维护事件一致性；

S1-6、将负责组织内聚类，解耦无关类的容器建模成模块；

S1-7、将聚集了相关实体和值对象到一致性边界内的容器建模成聚合，并选出某个实体作为聚合根代表此聚合；

S1-8、将负责存取操作聚合实例或提供聚合实例访问接口的对象建模成资源库；

S1-9、将具有创建复杂对象和聚合职责的单独对象建模成工厂。

2.根据权利要求1所述的一种领域驱动设计战术建模方法，其特征在于：在步骤S1-1中，战略建模需要与领域专家沟通，建立通用的业务语言即通用语言，明确业务的知识体系与核心诉求，从而发现要在模型中使用的主要的领域概念，然后进行划分领域和子域，明确领域边界，分析不同边界的特定职责，划分业务最小集；将不同的业务职责分配到不同的限界上下文中，并明确限界上下文映射关系；

在步骤S1-2中，实体是一个具有个性特征的对象，实体只根据唯一标识进行区分，而不是实体的属性，实体除了具有唯一性以外，在其生命周期中还具有可变性；

在步骤S1-3中，值对象可以度量和描述事物，值对象是不变对象，不需要任何标识，还应该尽量避免像实体对象一样的复杂性，值对象无法继续正确表达其状态时，度量和描述会进行改变，可以用另一个值对象直接替换，值对象的相等性通过比较两个对象的类型和属性来决定，值对象的方法必须是一个无副作用函数，即只用于产生输出，而不会修改值对象状态的方法；

在步骤S1-4中，领域服务以单独的接口或实现类的形式存在，负责领域中的某个操作或转换过程，领域服务关注实体和值对象职责之外的业务，在单个原子操作中处理多个领域对象，并且命名要与通用语言一致，此外，领域服务是无状态的；

在步骤S1-5中，领域事件捕获发生在领域中的领域专家所关心的事情，领域专家所关心的事情指在与专家进行讨论时，领域专家强调“当…时”的时候，将其建模成领域事件，领域事件中包含记录事件发生的时间的属性，还包含标识事件发送方的属性，方便准确把握事件的来源，当跨限界上下文或系统发布事件时，还需要使用唯一标识来将领域事件与其他对象进行区分；

在步骤S1-6中，模块将不同的内聚的类放在不同的模块中进行解耦，模块是一个命名的容器，用于存放内聚的类，并可以对不在同一个模块的类解耦；

在步骤S1-7中，聚合将实体和值对象聚类到一致性边界内，聚合不仅仅是聚集了一些共享父类、密切关联的对象，更加重要的是其更关注内部的不变条件和整体的一致性边界，从外部来看，聚合是一个原子性整体，聚合的所有操作都是事务的，聚合中需要选出一个实体充当聚合根，来充当聚合与外部交互的媒介；

在步骤S1-8中，资源库可以存储聚合实例，之后再通过资源库获取相同的聚合实例；

在步骤S1-9中，工厂是一种具有创建复杂对象和聚合职责的单独对象，该对象并不承担领域模型中的职责，但是依然是领域设计的一部分，工厂方法不承担任何业务逻辑，只有创建逻辑。

3.根据权利要求1所述的一种领域驱动设计战术建模方法，其特征在于：所述建模结果验证包括以下步骤：

S2-1、对战术模式的属性名和属性值的合法性进行验证；

S2-2、对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证；

S2-3、对战术模式之间关联关系的合理性进行验证，防止了战术模式间的非法连接。

4.根据权利要求3所述的一种领域驱动设计战术建模方法，其特征在于：在步骤S2-1中对战术模式的属性名和属性值合法性进行验证，包括以下步骤：

S2-1-1、保证实体的命名和唯一标识的命名符合英文语法规范，保证唯一标识命名和唯一标识具体值中不含有非法字符；

S2-1-2、保证值对象的命名符合英文文法规范；

S2-1-3、保证领域服务的命名符合英文语法规范，并与通用语言保持一致；

S2-1-4、保证领域事件的命名符合英文语法规范且能表示过去发生的含义，保证唯一标识命名和唯一标识具体值中不含有非法字符，保证事件发生时间属性是合法时间；

S2-1-5、保证模块的命名符合英文语法规范，并符合具体实现层面的规范；

S2-1-6、保证聚合的命名符合英文语法规范，保证根实体为聚合内部的实体；

S2-1-7、保证资源库的命名符合英文语法规范，并能反映出对象种类为资源库；

S2-1-8、保证工厂的命名符合英文语法规范，并能反映出对象种类为工厂。

5.根据权利要求3所述的一种领域驱动设计战术建模方法，其特征在于：在步骤S2-2中对战术模式必要属性是否缺失、属性值范围以及其他约束条件进行验证，包括以下步骤：

S2-2-1、保证实体必须含有且只能含有一个唯一标识属性，且对唯一标识取值范围进行规定，保证符合业务场景，保证实体是可以变化的；

S2-2-2、保证值对象不可改变，可以使用其他值对象进行替换，保证值对象中的方法都是无副作用行为；

S2-2-3、保证领域服务是无状态的；

S2-2-4、保证领域事件必须含有事件发生时间、事件发送方以及唯一标识属性，保证发生时间为过去时间，保证事件发送方对象不为空且属于业务领域范围内的对象，保证唯一标识取值范围合业务场景，保证领域对象不可变化；

S2-2-5、保证聚合内所有对象状态保持一致，且作为整体时所有操作都是原子性的，保证根实体不为空且为聚合内的实体对象；

S2-2-6、保证资源库的额外行为不包含业务逻辑，资源库连接的对象必须是合法的聚合或实体。

6.根据权利要求3所述的一种领域驱动设计战术建模方法，其特征在于：在步骤S2-3中对战术模式之间关联关系的合理性进行验证，防止战术模式间的非法连接，包括以下步骤：

S2-3-1、保证领域服务的输入必须连接至少一个实体或值对象；

S2-3-2、保证领域服务的输出必须连接至少一个值对象；

S2-3-3、保证领域事件的事件发送方属性必须与一个对象连接；

S2-3-4、保证模块必须至少连接一个对象；

S2-3-5、保证聚合必须包含一个根实体，且表示与外界连接时，只能连接聚合的根实体；

S2-3-6、保证资源库必须且只能和聚合根或实体连接。

7.根据权利要求1所述的一种领域驱动设计战术建模方法，其特征在于：所述实现建模结果包括以下步骤：

S3-1、为各个战术模式的重要属性实现选择技术方案；

S3-2、为各个战术模式的整体实现选择技术方案，并注意技术细节。

8.根据权利要求7所述的一种领域驱动设计战术建模方法，其特征在于：在步骤3-1中为各个战术模式的重要属性实现选择技术方案，包括以下步骤：

S3-1-1、为实体生成具有可读性的唯一标识；

S3-1-2、确定唯一标识的生成时间；

S3-1-3、使用操作命令的英文完成时态为领域事件命名；

S3-1-4、为领域事件对象定义记录发生时间的方法；

S3-1-5、为资源库添加全局接口，方便客户端进行访问，确保拥有资源库的聚合可以很方便地存取实例。

9.根据权利要求7所述的一种领域驱动设计战术建模方法，其特征在于：在步骤S3-2中为各个战术模式的整体实现选择技术方案，并注意技术细节，包括以下步骤：

S3-2-1、保持值对象不变性，确保除了初始化方法，其他任何方法都不能对该对象的属性状态进行修改；

S3-2-2、确保值对象的可比较性，值对象的相等性通过比较两个对象的类型和属性来决定；

S3-2-3、选择存储值对象集合的技术方案；

S3-2-4、选择实现领域服务的技术方案；

S3-2-5、保持领域事件的不变性，只允许领域事件对象构造函数全状态初始化，不提供修改属性的方法；

S3-2-6、保证订阅方在事件发生前订阅事件；

S3-2-7、保证领域模型和事件存储的一致性；

S3-2-8、选择转发领域事件的方式；

S3-2-9、同层模块出现耦合时，杜绝循环依赖；

S3-2-10、为资源库存储的聚合提供下一个带有顺序性的唯一标识。

Images