CN114386245A - 一种基于领域驱动设计对运维平台进行设计建模的方法 - Google Patents

Abstract

本发明公开了一种基于领域驱动设计对运维平台进行设计建模的方法，通过对各个领域对象进行业务划分得到子域和业务最小边界，并根据各个领域对象的子域和业务最小边界创建与设备相互映射的虚拟设备，同时整理出多个最小子域模型之间的关联，然后识别真实运维场景，并将这些数据在模型中进行关联编辑，使得通过本方法的运维平台建模过程可以通过最小的各个领域对象的子域和业务最小边界进行划分，从而不存在领域拆分和建模困难的问题，同时随着运维平台的发展和用户个性化需求不断提高，可以根据加设的内容建立不同的最小子域模型并与之前的模型进行融合，从而方便了后期的扩展处理。

Description

一种基于领域驱动设计对运维平台进行设计建模的方法

技术领域

本发明涉及领域驱动设计技术领域，更具体地说，本发明涉及一种基于领域驱动设计对运维平台进行设计建模的方法。

背景技术

运维职责贯穿了产品的生命周期，需要借助自动化、智能化的平台帮助运维工程师以最低的成本和最快的速度完成面向用户的服务交付和服务质量保障，运维平台主要由运维平台研发工程师理解业务需求后开发，主要包括：机器管理、资源管理、网络管理、架构基础设施、部署平台、配置管理平台、数据管理平台、监控平台、容量管理、流量管理、故障管理、业务调度平台、工作流引擎、权限管理、运维元数据管理和运维统一门户，而目前运维平台的建模方法存着在领域拆分和建模困难的问题，并且难以划分服务边界，所以当后期运维平台随着发展不断扩增，用户个性化需求不断提高，从而难以适用于不同业务的需求，而后期扩展较为困难，还需要重新进行建模处理，因此，研究一种基于领域驱动设计对运维平台进行设计建模的方法来解决上述问题具有重要意义。

发明内容

为了克服现有技术的上述缺陷，本发明的目的是提供一种基于领域驱动设计对运维平台进行设计建模的方法，可以通过最小的各个领域对象的子域和业务最小边界进行划分，从而不存在领域拆分和建模困难的问题，同时随着运维平台的发展和用户个性化需求不断提高，可以根据加设的内容建立不同的最小子域模型并与之前的模型进行融合，从而方便了后期的扩展处理。

为实现上述目的，本发明提供如下技术方案：

一种基于领域驱动设计对运维平台进行设计建模的方法，包括以下步骤：

S1、划分领域：

通过运维平台相关业务专家获取整个运维平台的真实业务细节并与相关专家统一通用语言，然后通过真实业务细节梳理出整个业务流程，由运维平台相关业务专家进行核对，确定运维平台的基本作用和业务范围，然后通过领域驱动设计技术对运维平台进行架构划分，得到核心域、支撑域和通用域，继续划分得到接口层、访问层、业务层、领域层、外部访问层和基础层。

S2、建模处理：

根据业务平台的业务类型、流程和规则确定多个领域对象，然后对各个领域对象进行业务划分得到子域和业务最小边界，并基于各个领域对象的子域和业务最小边界，在所述领域层对各个领域对象通过三维建模技术结合输入数据和嵌入式脚本语言，创建与设备相互映射的虚拟设备，得到各个领域的最小子域模型，然后根据最小子域模型的数据特征，预设相对应的基础设施层数据库，并根据基础设施层中存储数据的类型，将不同类型的数据分类存储在相应的数据库中。

S3、数据完善：

对每个最小子域模型进行数据采集，采集内容包括最小子域模型的属性名称、属性定义和特殊备注，并为每个最小子域模型确定维护角色，使得维护角色可以在后续使用的过程中对所需维护的每个最小子域模型进行准确性负责，以确定维护的职责边界，同时整理出多个最小子域模型之间的关联，然后识别真实运维场景，将每个流程以流程图的方式清晰的画出来，并将运维平台中资源状态的变化以状态变迁图的方式画出来，便于更好的基于场景和变更来控制配置项状态的变更，并将这些数据在模型中进行关联编辑，并将热点用颜色标识出来，同时在数据库中进行储存。

作为本发明的进一步方案：所述接口层用于提供面向外部接口声明和DTO对象，所述访问层用于提供HTTP访问入口，所述领域层用于提供DMO、VO、事件、数据访问对象，核心是按照领域进行分包，领域内高内聚，领域间低耦合，所述领域层和业务层包含的业务用途不同，所述业务层可以组合不同领域业务，并且可以增加流控、监控、日志和权限控制切面，相较于领域层更为丰富，提供BO对象，所述外部访问层用于在这个模块中调用外部RPC服务，解析返回码和返回数据，所述基础层包含缓存工具、消息队列、分布式锁和消息发送的基本功能。

作为本发明的进一步方案：所述S2中的输入数据包括传感器采集的数据和从设备存储器读取的数据，所述传感器设置于设备上。

作为本发明的进一步方案：所述S3中在流程图的绘制过程中，行作为角色，列作为阶段，而在每个阶段中,运维平台的状态都有可能发生改变，需要将改变进行记录，方便后续人员在做相应的流程实现的过程中，控制这类状态。

作为本发明的进一步方案：所述建模方法有事件风暴、影响地图和模型讨论旋涡。

作为本发明的进一步方案：所述S3中进行颜色标识的过程中，使用标准的事件风暴便利贴颜色，所述标准的事件风暴便利贴颜色包括：蓝色、粉色长条、紫色长条和绿色，所述蓝色指代动作/命令，所述粉色长条代表系统，所述紫色长条代表策略/最终的业务约束，所述绿色代表信息。

作为本发明的进一步方案：所述S1中统一通用语言时要避免二义性，需要使用修饰、限定、说明名词或代词的品质与特征的定语语句来更加详细的描述问题。

作为本发明的进一步方案：所述核心域为系统的核心部分，也是业务的盈利来源，它需要投入最好的开发人员进行研发，所述支撑域非系统的业务核心，但是没有它系统就无法运转，由于存在部分的差异化，需要通过外包进行个性化的定制，所述通用域不是业务的核心，但是在业内非常常见，有现成的解决方案可以直接购买，或者使用初级开发人员进行开发。

本发明的有益效果在于：

本发明通过与业务专家进行配合来了解整个运维平台的真实业务细节，并通过领域驱动设计技术对运维平台进行架构划分，然后根据业务平台的业务类型、流程和规则确定多个领域对象，然后对各个领域对象进行业务划分得到子域和业务最小边界，并根据各个领域对象的子域和业务最小边界创建与设备相互映射的虚拟设备，得到各个领域的最小子域模型，然后为每个最小子域模型确定维护角色，同时整理出多个最小子域模型之间的关联，然后识别真实运维场景，并将这些数据在模型中进行关联编辑，并将热点用颜色标识出来，同时在数据库中进行储存，使得通过本方法的运维平台建模过程可以通过最小的各个领域对象的子域和业务最小边界进行划分，从而不存在领域拆分和建模困难的问题，同时随着运维平台的发展和用户个性化需求不断提高，可以根据加设的内容建立不同的最小子域模型并与之前的模型进行融合，从而方便了后期的扩展处理。

附图说明

图1为本发明一种基于领域驱动设计对运维平台进行设计建模的方法的流程图。

具体实施方式

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

如图所示，一种基于领域驱动设计对运维平台进行设计建模的方法，包括以下步骤：

S1、划分领域，基于真实业务梳理流程，由业务专家进行确认，最终划分领域

通过运维平台相关业务专家获取整个运维平台的真实业务细节并与相关专家统一通用语言，然后通过真实业务细节梳理出整个业务流程，由运维平台相关业务专家进行核对，确定运维平台的基本作用和业务范围，然后通过领域驱动设计技术对运维平台进行架构划分，得到核心域、支撑域和通用域，继续划分得到接口层、访问层、业务层、领域层、外部访问层和基础层。

S2、建模处理，根据平台业务类型、流程和规则确定领域对象，再根据领域对象业务职能划分子域和领域聚合对象等完成领域建模

根据业务平台的业务类型、流程和规则确定多个领域对象，然后对各个领域对象进行业务划分得到子域和业务最小边界，并基于各个领域对象的子域和业务最小边界，在领域层对各个领域对象通过三维建模技术结合输入数据和嵌入式脚本语言，创建与设备相互映射的虚拟设备，得到各个领域的最小子域模型，然后根据最小子域模型的数据特征，预设相对应的基础设施层数据库，并根据基础设施层中存储数据的类型，将不同类型的数据分类存储在相应的数据库中。

S3、数据完善，整理最小子域模型及其关联关系，识别运维场景通过流程将资源状态变化在数据库中进行持久化

对每个最小子域模型进行数据采集，采集内容包括最小子域模型的属性名称、属性定义和特殊备注，并为每个最小子域模型确定维护角色，使得维护角色可以在后续使用的过程中对所需维护的每个最小子域模型进行准确性负责，以确定维护的职责边界，同时整理出多个最小子域模型之间的关联，然后识别真实运维场景，将每个流程以流程图的方式清晰的画出来，并将运维平台中资源状态的变化以状态变迁图的方式画出来，便于更好的基于场景和变更来控制配置项状态的变更，并将这些数据在模型中进行关联编辑，并将热点用颜色标识出来，同时在数据库中进行储存。

接口层用于提供面向外部接口声明和DTO对象，访问层用于提供HTTP访问入口，领域层用于提供DMO、VO、事件、数据访问对象，核心是按照领域进行分包，领域内高内聚，领域间低耦合，领域层和业务层包含的业务用途不同，业务层可以组合不同领域业务，并且可以增加流控、监控、日志和权限控制切面，相较于领域层更为丰富，提供BO对象，外部访问层用于在这个模块中调用外部RPC服务，解析返回码和返回数据，基础层包含缓存工具、消息队列、分布式锁和消息发送的基本功能。

S2中的输入数据包括传感器采集的数据和从设备存储器读取的数据，传感器设置于设备上。

S3中在流程图的绘制过程中，行作为角色，列作为阶段，而在每个阶段中,运维平台的状态都有可能发生改变，需要将改变进行记录，方便后续人员在做相应的流程实现的过程中，控制这类状态。

建模方法有事件风暴、影响地图和模型讨论旋涡。

S3中进行颜色标识的过程中，使用标准的事件风暴便利贴颜色，标准的事件风暴便利贴颜色包括：蓝色、粉色长条、紫色长条和绿色，蓝色指代动作/命令，粉色长条代表系统，紫色长条代表策略/最终的业务约束，绿色代表信息。

S1中统一通用语言时要避免二义性，需要使用修饰、限定、说明名词或代词的品质与特征的定语语句来更加详细的描述问题。

核心域为系统的核心部分，也是业务的盈利来源，它需要投入最好的开发人员进行研发，支撑域非系统的业务核心，但是没有它系统就无法运转，由于存在部分的差异化，需要通过外包进行个性化的定制，通用域不是业务的核心，但是在业内非常常见，有现成的解决方案可以直接购买，或者使用初级开发人员进行开发。

本发明通过与业务专家进行配合来了解整个运维平台的真实业务细节，并通过领域驱动设计技术对运维平台进行架构划分，然后根据业务平台的业务类型、流程和规则确定多个领域对象，然后对各个领域对象进行业务划分得到子域和业务最小边界，并根据各个领域对象的子域和业务最小边界创建与设备相互映射的虚拟设备，得到各个领域的最小子域模型，然后为每个最小子域模型确定维护角色，同时整理出多个最小子域模型之间的关联，然后识别真实运维场景，并将这些数据在模型中进行关联编辑，并将热点用颜色标识出来，同时在数据库中进行储存，使得通过本方法的运维平台建模过程可以通过最小的各个领域对象的子域和业务最小边界进行划分，从而不存在领域拆分和建模困难的问题，同时随着运维平台的发展和用户个性化需求不断提高，可以根据加设的内容建立不同的最小子域模型并与之前的模型进行融合，从而方便了后期的扩展处理。

最后应说明的几点是：虽然，上文中已经用一般性说明及具体实施例对本发明作了详尽的描述，但在本发明的基础上，以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (6)

1.一种基于领域驱动设计对运维平台进行设计建模的方法，其特征在于，包括以下步骤：

S1、划分领域：

通过运维平台业务专家获取整个运维平台的真实业务细节并与专家统一通用语言，然后通过真实业务细节梳理出整个业务流程，由运维平台业务专家进行核对，确定运维平台的基本作用和业务范围，然后通过领域驱动设计技术对运维平台进行架构划分，得到核心域、支撑域和通用域，继续划分得到接口层、访问层、业务层、领域层、外部访问层和基础层；

S2、建模处理：

根据业务平台的业务类型、流程和规则确定多个领域对象，然后对各个领域对象进行业务划分得到子域和业务最小边界，并基于各个领域对象的子域和业务最小边界，在所述领域层对各个领域对象通过三维建模技术结合输入数据和嵌入式脚本语言，创建与设备相互映射的虚拟设备，得到各个领域的最小子域模型，然后根据最小子域模型的数据特征，预设相对应的基础设施层数据库，并根据基础设施层中存储数据的类型，将不同类型的数据分类存储在相应的数据库中；

S3、数据完善：

对每个最小子域模型进行数据采集，采集内容包括最小子域模型的属性名称、属性定义和特殊备注，并为每个最小子域模型确定维护角色，使得维护角色在后续使用的过程中对所需维护的每个最小子域模型进行准确性负责，以确定维护的职责边界，同时整理出多个最小子域模型之间的关联，然后识别真实运维场景，将每个流程以流程图的方式清晰的画出来，并将运维平台中资源状态的变化以状态变迁图的方式画出来，便于基于场景和变更来控制配置项状态的变更，并将这些数据在模型中进行关联编辑，并将热点用颜色标识出来，同时在数据库中进行储存。

2.根据权利要求1所述的一种基于领域驱动设计对运维平台进行设计建模的方法，其特征在于：所述S1中，接口层用于提供面向外部接口声明和DTO对象，所述访问层用于提供HTTP访问入口，所述领域层用于提供DMO、VO、事件、数据访问对象，核心是按照领域进行分包，领域内高内聚，领域间低耦合，所述领域层和业务层包含的业务用途不同，所述业务层可以组合不同领域业务，并且可以增加流控、监控、日志和权限控制切面，相较于领域层更为丰富，提供BO对象，所述外部访问层用于在这个模块中调用外部RPC服务，解析返回码和返回数据，所述基础层包含缓存工具、消息队列、分布式锁和消息发送的基本功能。

3.根据权利要求1所述的一种基于领域驱动设计对运维平台进行设计建模的方法，其特征在于：所述S2中的输入数据包括传感器采集的数据和从设备存储器读取的数据，所述传感器设置于设备上。

4.根据权利要求1所述的一种基于领域驱动设计对运维平台进行设计建模的方法，其特征在于：所述S3中在流程图的绘制过程中，行作为角色，列作为阶段，而在每个阶段中,运维平台的状态发生改变时，将改变进行记录，方便后续人员在做相应的流程实现的过程中，控制这类状态。

5.根据权利要求1所述的一种基于领域驱动设计对运维平台进行设计建模的方法，其特征在于：所述S3中进行颜色标识的过程中，使用标准的事件风暴便利贴颜色，所述标准的事件风暴便利贴颜色包括：蓝色、粉色长条、紫色长条和绿色，所述蓝色指代动作/命令，所述粉色长条代表系统，所述紫色长条代表策略/最终的业务约束，所述绿色代表信息。

6.根据权利要求1所述的一种基于领域驱动设计对运维平台进行设计建模的方法，其特征在于：所述S1中统一通用语言时要避免二义性，使用修饰、限定、说明名词或代词的品质与特征的定语语句来更加详细的描述问题。

Images