用于领域驱动战术设计的方法、装置及存储机制

技术领域

本申请涉及领域驱动设计技术领域，具体地涉及一种用于领域驱动战术设计的方法、装置及存储介质。

背景技术

领域驱动设计指出领域层是这套模型的精髓，与面向数据开发模式相比，领域层模型能够更好的反映出业务本质问题，这一特点使其在大型复杂软件开发中优势明显，能够快速应对需求的变化和迭代。战术设计是领域驱动设计的实践环节，将实体、值对象、领域服务、领域事件等软件中模型(领域对象)映射到代码，同时使用聚合、工厂、资源库等模式来管理这些领域对象的生命周期，维护领域对象业务完整性和一致性，防止对象实现偏离领域驱动设计的轨道。战术设计作为领域驱动设计的基础，决定整套设计方案能否成功落地实现。

然而领域驱动战术设计仍然面临挑战，体现在以下几个方面：①战术建模过程中得到很多概念、事件、行为等元素，但是缺少具体的形式化表达将这些元素和整个业务流程绑定，导致模型创建不完全或者和实际业务有偏差。②领域模型侧重于业务而非技术，在技术实现的过程中需要一些技术模型来将业务模型关联管理起来，方便梳理业务模型关系、实现和维护。③领域对象的生命周期管理存在一定难度，领域对象的各个生命周期阶段都有一定规则，生命周期转换存在复杂性，难以封装维护。

现有技术中所采用的领域驱动战术设计的方法存在业务模型的构建存在偏差以及业务模型不便于管理和维护的问题。

发明内容

本申请实施例的目的是提供一种用于领域驱动战术设计的方法、装置及存储介质，用以解决现有技术中所采用的领域驱动战术设计的方法存在业务模型的构建存在偏差以及业务模型不便于管理和维护的问题。

为了实现上述目的，本申请第一方面提供一种用于领域驱动战术设计的方法，该方法包括：

通过目标业务的战略模式划分界限上下文；

确定界限上下文对应的业务状态流程图；

通过业务状态流程图构建领域模型和状态机模型；

根据领域模型和状态机模型得到目标业务对应的目标代码。

在本申请实施例中，确定界限上下文对应的业务状态流程图包括：

通过事件风暴确定目标业务中的多个事件；

确定每个事件对应的状态和行为；

根据每个事件以及每个事件对应的状态和行为绘制业务状态流程图。

在本申请实施例中，领域模型包括实体、值对象、领域事件和领域服务，通过业务状态流程图构建领域模型包括：

将目标业务中存在状态变更的对应建模为实体；

将目标业务中不涉及状态变更的对象建模为值对象；

将业务状态流程图中的事件建模为领域事件；

将业务状态流程图中的不属于实体或值对象自然职责的行为建模为领域服务。

在本申请实施例中，该方法还包括：

通过状态机模型对领域模型中实体的生命周期进行管理。

在本申请实施例中，通过业务状态流程图构建状态机模型包括：

定义状态机的基本功能；

根据状态机的基本功能结合业务状态流程图分别确定目标业务中每个实体的状态流转模型，以得到目标业务对应的状态机模型。

在本申请实施例中，定义状态机的基本功能包括：

定义状态机的属性集合

定义状态机的加载行为；

定义状态机的扭转行为；

定义状态机的事件发布行为。

在本申请实施例中，状态机的属性集合包括：

实体标识、事件、初态、次态和行为。

在本申请实施例中，状态机模型中任意实体的状态流转模型中包括多条属性数据，相邻两条属性数据中，上一条属性数据中的次态与下一条属性数据中的初态相同。

本申请第二方面提供一种用于领域驱动战术设计的装置，包括：

存储器，被配置成存储指令；以及

处理器，被配置成从存储器调用指令以及在执行指令时能够实现上述的用于领域驱动战术设计的方法。

本申请第三方面提供一种机器可读存储介质，其特征在于，该机器可读存储介质上存储有指令，该指令用于使得机器执行上述的用于领域驱动战术设计的方法。

通过上述技术方案，先通过目标业务的战略模式划分界限上下文；再确定界限上下文对应的业务状态流程图；接着通过业务状态流程图构建领域模型和状态机模型；最后根据领域模型和状态机模型得到目标业务对应的目标代码。本申请通过可配置的状态机模型，可以快速实现目标业务的领域驱动建模和落地，快速得到目标代码，并且可以通过可配置的状态机模型对领域模型进行管理，有利于提高模型构建的精确度以及便于后期维护。

本申请实施例的其它特征和优点将在随后的具体实施方式部分予以详细说明。

附图说明

附图是用来提供对本申请实施例的进一步理解，并且构成说明书的一部分，与下面的具体实施方式一起用于解释本申请实施例，但并不构成对本申请实施例的限制。在附图中：

图1为本申请实施例提供的一种用于领域驱动战术设计的方法的流程示意图；

图2为本申请一具体实施例提供的一种仓储系统的收货业务的业务状态流程图的流程示意图；

图3为本申请实施例提供的一种用于领域驱动战术设计的装置的结构框图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解的是，此处所描述的具体实施方式仅用于说明和解释本申请实施例，并不用于限制本申请实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明，若本申请实施例中有涉及方向性指示(诸如上、下、左、右、前、后……)，则该方向性指示仅用于解释在某一特定姿态(如附图所示)下各部件之间的相对位置关系、运动情况等，如果该特定姿态发生改变时，则该方向性指示也相应地随之改变。

另外，若本申请实施例中有涉及“第一”、“第二”等的描述，则该“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

图1为本申请实施例提供的一种用于领域驱动战术设计的方法的流程示意图。如图1所示，本申请实施例提供一种用于领域驱动战术设计的方法，该方法可以包括下列步骤：

步骤101、通过目标业务的战略模式划分界限上下文；

步骤102、确定界限上下文对应的业务状态流程图；

步骤103、通过业务状态流程图构建领域模型和状态机模型；

步骤104、根据领域模型和状态机模型得到目标业务对应的目标代码。

在本申请实施例中，领域驱动战术设计是领域驱动设计中的一种，领域驱动设计分为战略设计和战术设计两个层面，战略设计的功能是划分领域、确定领域的边界和关系，以使得业务领域清晰，明确界限上下文。而领域驱动战术设计是是一种软件设计方法，其目标是通过领域建模降低复杂软件设计和实现难度，领域建模，绑定模型和实现，是领域驱动设计的最终落地实现阶段。

在本申请实施例中，为例解决领域驱动设计中建模难、实现难、领域对象生命周期管理难和领域问题迭代导致实体规则发送变化等问题。本申请实施例采用基于可配置化状态机的领域驱动战术设计方法，以实现对基于状态管理的业务场景快速进行领域建模和落地。具体地，先基于目标业务的战略模式划分出界限上下文。其中，目标业务是指领域驱动战术设计的对象。进一步地，为便于后续进行领域建模，可以先根据目标业务的界限上下问确定对应的业务状态流程图。在一个示例中，可以先通过事件风暴等方式梳理出目标业务的界限上下文中的多个事件，以及每个事件对应的状态和行为，再根据各个事件及其分别对应的状态和行为绘制业务状态流程图。

在本申请实施例中，在确定目标业务对应的业务状态流程图后，可以通过业务状态流程图进行领域建模和可配置化状态机建模，以得到领域模型和状态机模型。领域模型包括实体、值对象、领域事件和领域服务。状态机是一种表示状态之间转移和动作的数学模型，主要有以下四个要素组成：状态、转移、转移条件、动作。状态分为初态和次态，初态在满足条件之后会转移到次态；转移是状态的扭转流程；转移条件也称作事件，事件的发生会导致转态的转移和动作的发生；动作是在转移条件满足之后执行的内容。状态机能够很好的控制软件实现中的业务流程，基本的工作方式是当某个事件发生之后，根据当前状态去执行相应的动作，然后扭转到下一个状态。最后，根据领域模型和状态机模型得到目标业务对应的目标代码，以完成目标业务对应的软件设计的实现。

通过上述技术方案，先通过目标业务的战略模式划分界限上下文；再确定界限上下文对应的业务状态流程图；接着通过业务状态流程图构建领域模型和状态机模型；最后根据领域模型和状态机模型得到目标业务对应的目标代码。本申请通过可配置的状态机模型，可以快速实现目标业务的领域驱动建模和落地，快速得到目标代码，并且可以通过可配置的状态机模型对领域模型进行管理，有利于提高模型构建的精确度以及便于后期维护。

在本申请实施例中，确定界限上下文对应的业务状态流程图可以包括：

通过事件风暴确定目标业务中的多个事件；

确定每个事件对应的状态和行为；

根据每个事件以及每个事件对应的状态和行为绘制业务状态流程图。

在本申请实施例中，为便于后续进行领域建模，可以先根据目标业务的界限上下问确定对应的业务状态流程图。具体地，先通过事件风暴等方式梳理出目标业务的界限上下文中的多个事件，以及每个事件对应的状态和行为，再根据各个事件及其分别对应的状态和行为绘制业务状态流程图。其中，事件对应的状态包括初态和次态，初态即发生此事件之前需要达到的状态，次态即事件发生后的对应的状态。事件对应的行为是指某个事件发生后可能产生的行为。

在本申请实施例中，领域模型包括实体、值对象、领域事件和领域服务，通过业务状态流程图构建领域模型可以包括：

将目标业务中存在状态变更的对应建模为实体；

将目标业务中不涉及状态变更的对象建模为值对象；

将业务状态流程图中的事件建模为领域事件；

将业务状态流程图中的不属于实体或值对象自然职责的行为建模为领域服务。

在本申请实施例中，在确定目标业务对应的业务状态流程图后，可以通过业务状态流程图进行领域建模，以得到领域模型。领域模型包括实体、值对象、领域事件和领域服务。在本申请实施例中，可以将目标业务中存在状态变更的对象建模为实体，定义实体的唯一标识、状态以及其他业务属性，并将状态机中属于实体自然职责的行为或事件定义为实体的行为。进一步地，将目标业务中用来描述事务不涉及状态变更的对象建模为值对象，定义值对象的业务属性，并将业务状态流程图中的事件建模为领域事件。进一步地，将业务状态流程图中的事件建模为领域事件，并定义领域事件的事件属性，包括事件、行为人、实体以及事件标识等信息。最后，会业务状态流程图中的行为进行分析，将不属于实体或者值对象自然职责的行为建模为领域服务。

如此。通过构建好的领域模型能够很好映射业务问题，减少领域专家和开发团队之间的沟通障碍，基于模型的软件实现能够快速应对复杂需求的迭代和变化。

在本申请实施例中，通过业务状态流程图构建状态机模型可以包括：

定义状态机的基本功能；

根据状态机的基本功能结合业务状态流程图分别确定目标业务中每个实体的状态流转模型，以得到目标业务对应的状态机模型。

在本申请实施例中，在确定目标业务对应的业务状态流程图后，可以通过业务状态流程图进行可配置化状态机建模，以得到状态机模型。其中，状态机是一种表示状态之间转移和动作的数学模型，主要有以下四个要素组成：状态、转移、转移条件、动作。状态分为初态和次态，初态在满足条件之后会转移到次态；转移是状态的扭转流程；转移条件也称作事件，事件的发生会导致转态的转移和动作的发生；动作是在转移条件满足之后执行的内容。状态机能够很好的控制软件实现中的业务流程，基本的工作方式是当某个事件发生之后，根据当前状态去执行相应的动作，然后扭转到下一个状态。

具体地，先基于业务状态流程图定义状态机的基本功能，即状态机通用功能建模。进一步地，进行业务状态流程图中实体的状态机建模，根据状态机的基本功能结合业务状态流程图分别确定目标业务中每个实体的状态流转模型，以得到目标业务对应的状态机模型。在一示例中，可以根据业务状态流程图梳理出实体所有的状态变化场景，明确当前场景下的状态、事件和行为，每一种场景对应状态机的一条配置。

在本申请实施例中，定义状态机的基本功能可以包括：

定义状态机的属性集合

定义状态机的加载行为；

定义状态机的扭转行为；

定义状态机的事件发布行为。

在本申请实施例中，定义状态机的基本功能即对状态机的通用功能进行建模。在本申请实施例中，由于对状态机的功能配置一般是多条，因此可以定义一个属性集合，以便根据属性集合中的各个元素进行功能配置。

在本申请实施例中，状态机的属性集合可以包括：

实体标识、事件、初态、次态和行为。

具体地，实体标识是指实体的唯一标识，事件是指具体的业务流程事件，一个实体可以对应多个事件，事件对应的状态包括初态和次态，初态即发生此事件之前需要达到的状态，次态即事件发生后的对应的状态。事件对应的行为是指某个事件发生后可能产生的行为。

在本申请实施例中，状态机模型中任意实体的状态流转模型中包括多条属性数据，相邻两条属性数据中，上一条属性数据中的次态与下一条属性数据中的初态相同。

在本申请实施例中，该方法还可以包括：

通过状态机模型对领域模型中实体的生命周期进行管理。

具体地，为了提高状态机的适用性，可以定义相应的加载策略保证配置的变化能被状态机更新。即定义状态机的加载行为，进行对对加载行为进行配置。其中，配置加载行为是用来通过实体标识加载实体的状态机配置。进一步地，定义状态机的扭转行为，状态扭转行为用来通过初态和事件获取次态，同时执行状态机中配置的行为。最后，定义状态机的事件发布行为，事件发布行为用来将事件发布出去，关注此事件的业务可监听此事件，并做出相应的业务操作。

在本申请实施例中，在构建好领域模型之后，可以基于目标业务完成领域模型技术的实现，包括实体技术实现以及引入状态机管理、值对象技术实现、领域事件技术实现和领域服务技术实现。

具体地，实体技术实现以及引入状态机管理包括：通过相关算法生成具有可读性的唯一字符串，以确定实体标识，实体标识是实体的唯一标识。然后定义实体状态值，状态值具有业务语义，可读性好。进一步地，定义实体的行为，并在实体的行为中通过状态机管理实体的生命周期，控制实体自身状态的流转，同时可在状态机中执行特定行为来达到实体的一些特定规则被满足的要求，比如一些规则校验等。并且由于状态机支持可配置化，即使实体的生命周期扭转规则发生变化或者固定规则发生变化，也可以很好的应对，解决实体生命周期管理难的问题。

在本申请实施例中，值对象的技术实现不提供修改值对象属性的方法，需要保证值对象是不可变更的，修改值对象需要通过整体替换实现。

在本申请实施例中，领域事件技术实现可以包括：确定领域事件的事件名称，在一个示例中，领域事件的事件名称可以采用操作命令名加事件后缀的形式确定，如此业务语义更加明确。进一步地，领域对象创建时，可以为其初始化关键属性，例如事件、行为人、实体和事件标识等属性，同时需要保证属性的不可变性。在一个示例中，可以通过状态机将领域事件发布到事件中心，由事件中心统一管控，如此，业务方可以根据实际需求在事件中心监听对应的事件。

在本申请实施例中，领域服务技术实现可以包括：确定领域服务的服务名称。在一个示例中，领域服务的服务名称可以采用领域实体名称加服务后缀确定，如此，业务语义更加清晰。在另一个试了下，需要保证领域服务无状态或者状态不可变更，以确保在多线程中使用线程安全。

通过上述技术方案，先通过目标业务的战略模式划分界限上下文；再确定界限上下文对应的业务状态流程图；接着通过业务状态流程图构建领域模型和状态机模型；最后根据领域模型和状态机模型得到目标业务对应的目标代码。本申请通过可配置的状态机模型，可以快速实现目标业务的领域驱动建模和落地，快速得到目标代码，并且可以通过可配置的状态机模型对领域模型进行管理，有利于提高模型构建的精确度以及便于后期维护。

在本申请一具体实施例中，以仓储系统的收货业务为例，基于上述用于领域驱动战术设计的方法对仓储系统的收货业务进行基于可配置状态机的领域驱动战术设计。其实现步骤如下：

一、在收货界限上下文中，梳理业务中出现的事件、状态、行为和一些关键词，主要有收货、待称重、待收货、已收货、质检、称重、毛重、皮重、待去皮等关键词。

二、图2为本申请一具体实施例提供的一种仓储系统的收货业务的业务状态流程图的流程示意图。基于上述事件、状态、行为绘制基于状态机的业务状态流程图，如图2所示。

三、基于业务状态流程图创建领域模型

给图2中出现的关键词定义英文标识如下：receiptOrder为收货单，weightOrder为称重单，qualityInspection为质检，waitingWeigh为待称重，waitingReceive为待收货，receiveFinished为收货完成，waitingTare为待去皮重，grossWeigh为称毛重，tareWeigh为称皮重，weighFinished为称重完成。

收货单、称重单、质检单建模为实体，分名命名为ReceiptOrderEntity、WeightOrderEntity、QualityInspectionOrderEntity，将称毛重(grossWeigh)、称皮重(tareWeigh)定义为WeightOrderEntity的行为。质检、称毛重、称皮重事件建模为领域事件，分别命名为QualityInspectionEvent、GrossWeighEvent、TareWeighEvent。创建收货单领域服务命名为ReceiptOrderService，将质检(qualityInspection)和称重(weigh)定义为它的行为。

四、基于业务状态流程图梳理实体状态机模型

梳理出实体ReceiptOrderEntity收货单和实体WeightOrderEntity称重单的状态扭转场景，如表1所示，确定收货业务的状态流转表。表1为收货业务的状态流转表。

表1

五、收货业务模型技术实现

按照上述模型技术实现步骤，将状态机、实体、值对象、领域事件、领域服务等映射到代码，用状态机管理ReceiptOrderEntity和WeightOrderEntity的生命周期，状态机的可配置可应对一些业务变化。例如：当前收货单还未质检就去称重，则提示”请先质检再称重”。如果以后不需要质检了，只需要修改状态机配置就可实现此需求。

本发明提供了一种基于可配置化状态机的领域驱动战术设计方法，在一些基于状态管理的业务场景下可快速的进行领域建模和落地。同时可配置化的状态机可以很好解决领域对象生命周期管理难、领域问题迭代导致规则发生变化需要修改代码等问题。

图3为本申请实施例提供的一种用于领域驱动战术设计的装置的结构框图。如图3所示，本申请实施例提供一种用于领域驱动战术设计的装置，可以包括：

存储器310，被配置成存储指令；以及

处理器320，被配置成从存储器310调用指令以及在执行指令时能够实现上述的用于领域驱动战术设计的方法。

具体地，在本申请实施例中，处理器320可以被配置成：

通过目标业务的战略模式划分界限上下文；

确定界限上下文对应的业务状态流程图；

通过业务状态流程图构建领域模型和状态机模型；

根据领域模型和状态机模型得到目标业务对应的目标代码。

进一步地，处理器320还可以被配置成：

通过事件风暴确定目标业务中的多个事件；

确定每个事件对应的状态和行为；

根据每个事件以及每个事件对应的状态和行为绘制业务状态流程图。

进一步地，处理器320还可以被配置成：

在本申请实施例中，领域模型包括实体、值对象、领域事件和领域服务，通过业务状态流程图构建领域模型包括：

将目标业务中存在状态变更的对应建模为实体；

将目标业务中不涉及状态变更的对象建模为值对象；

将业务状态流程图中的事件建模为领域事件；

将业务状态流程图中的不属于实体或值对象自然职责的行为建模为领域服务。

进一步地，处理器320还可以被配置成：

通过状态机模型对领域模型中实体的生命周期进行管理。

进一步地，处理器320还可以被配置成：

在本申请实施例中，通过业务状态流程图构建状态机模型包括：

定义状态机的基本功能；

根据状态机的基本功能结合业务状态流程图分别确定目标业务中每个实体的状态流转模型，以得到目标业务对应的状态机模型。

进一步地，处理器320还可以被配置成：

定义状态机的属性集合

定义状态机的加载行为；

定义状态机的扭转行为；

定义状态机的事件发布行为。

在本申请实施例中，状态机的属性集合包括：

实体标识、事件、初态、次态和行为。

在本申请实施例中，状态机模型中任意实体的状态流转模型中包括多条属性数据，相邻两条属性数据中，上一条属性数据中的次态与下一条属性数据中的初态相同。

通过上述技术方案，先通过目标业务的战略模式划分界限上下文；再确定界限上下文对应的业务状态流程图；接着通过业务状态流程图构建领域模型和状态机模型；最后根据领域模型和状态机模型得到目标业务对应的目标代码。本申请通过可配置的状态机模型，可以快速实现目标业务的领域驱动建模和落地，快速得到目标代码，并且可以通过可配置的状态机模型对领域模型进行管理，有利于提高模型构建的精确度以及便于后期维护。

本申请实施例还提供一种机器可读存储介质，该机器可读存储介质上存储有指令，该指令用于使得机器执行上述的用于领域驱动战术设计的方法。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。