CN114546367A - 一种信息处理方法及装置、设备、存储介质 - Google Patents

Abstract

本申请公开了一种信息处理方法，包括：输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；将所述修改后的业务模型输出至所述至少两个页面。本申请还公开了实现上述信息处理方法的装置、设备、存储介质。

Description

一种信息处理方法及装置、设备、存储介质

技术领域

本申请实施例涉及计算机技术领域，涉及但不限于一种信息处理方法及装置、设备、存储介质。

背景技术

随着互联网的深入发展，软件所承载的通用业务范围和逻辑越来越复杂。企业的面向企业(ToB)业务扩展，面临着定制化、差异化严重的问题。作为软件开发任务、产品设计人员、业务运营，如何应对复杂的业务逻辑、大量差异化的业务，是每一个软件参与者需要面临的迫切问题。领域驱动设计(Domain Driven Design，DDD)作为一种软件思想，用于解决复杂业务的建模，来指导繁杂的业务开发。但是DDD对于新手门槛高，产品与业务运营难参与到建模，难以统一语言。

发明内容

本申请实施例为解决相关技术中存在的至少一个问题而提供一种信息处理方法及装置、设备、存储介质，能够降低DDD的使用门槛。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种信息处理方法，所述方法包括：

输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；

接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；

将所述修改后的业务模型输出至所述至少两个页面。

第二方面，本申请实施例提供一种信息处理装置，包括：

第一输出模块，用于输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；

接收模块，用于接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；

所述第一输出模块，还用于将所述修改后的业务模型输出至所述至少两个页面。

第三方面，本申请实施例提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器运行所述计算机程序时实现上述信息处理方法中的步骤。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器运行时实现上述信息处理方法中的步骤。

本申请实施例中，提供了一种信息处理方法及装置、设备、存储介质，包括：输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；将所述修改后的业务模型输出至所述至少两个页面，从而能够输出页面内容为业务模型的模型元素组件的页面，且同时输出多个针对不同用户的页面，当一个用户对业务模型的模型元素组件进行操作时，将操作结果输出至多个页面中，使得业务模型可视化的同时，保证不同用户看到的可视化业务模型的内容同步，从而降低DDD的使用门槛。

附图说明

图1为本申请实施例信息处理系统的可选地架构示意图；

图2为本申请实施例信息处理系统的可选地架构示意图；

图3为本申请实施例提供的信息处理方法的可选地流程示意图；

图4为本申请实施例提供的页面显示效果示意图；

图5为本申请实施例提供的可视化建模平台建模的可选地架构示意图；

图6为本申请实施例提供的可视化建模平台建模的可选地架构示意图；

图7为本申请实施例提供的可视化建模平台的可选地结构示意图；

图8为本申请实施例提供的信息处理方法的可选地流程示意图；

图9为本申请实施例提供的信息处理方法的可选地流程示意图；

图10为本申请实施例提供的信息处理方法的可选地流程示意图；

图11为本申请实施例提供的信息处理方法的可选地流程示意图；

图12为本申请实施例提供的信息处理装置的可选地结构示意图；

图13为本申请实施例提供的电子设备的可选地结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对申请的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

本申请实施例可提供为信息处理方法及系统和存储介质。实际应用中，信息处理方法可由信息处理系统实现，信息处理系统中的各功能实体可以由电子设备(如终端设备或服务器)的硬件资源，如处理器等计算资源、通信资源(如用于支持实现光缆、蜂窝等各种方式通信)协同实现。

本申请实施例的信息处理方法可应用于图1所示的信息处理系统10，包括：客户端101和服务端102，其中，客户端101中运行有能够显示页面的程序，比如：浏览器或应用程序(APP)，能够接收用户输入的数据。服务端102能够接收客户端发送的数据，并基于接收的数据建立业务模型。这里，客户端101和服务端102之间可通过网络103进行通信。

本申请实施例中，服务端输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述第一页面中任一页面；将所述修改后的业务模型输出至所述至少两个页面。

在实际应用中，服务端可提供可视化建模系统，基于可视化建模系统实施本申请实施例提供的信息处理方法。

这里，客户端101可显示至少两个页面中任一页面。

在一示例中，如图2所示，服务端102连接有第三个客户端：客户端101-1、客户端101-2和客户端101-3。其中，客户端101-1、客户端101-2和客户端101-3分别用于显示至少两个页面中的第一页面、第二页面和第三页面，且客户端101-1为针对业务人员的客户端，客户端101-2是针对产品人员的客户端，客户端101-3是针对研发人员的客户端。

本申请实施例中，服务端可以是任何具有信息处理能力的电子设备，在一种实施例中，电子设备可以是智能终端，例如可以是笔记本等具有无线通信能力的移动终端。在另一种实施例中，电子设备还可以是不便移动的具有计算功能的终端设备，比如台式计算机、桌面电脑、服务器等。

结合上述信息处理系统，本实施例提出一种信息处理方法，能够降低DDD的使用门槛。

下面，结合图1或图2所示的信息处理系统，对本申请实施例提供的信息处理方法、装置、设备和存储介质的各实施例进行说明。

本申请实施例提供一种信息处理方法。该方法所实现的功能可以通过电子设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该电子设备至少包括处理器和存储介质。

图3为本申请实施例的一种信息处理方法的实现流程示意图，应用于服务端，如图3所示，该方法可以包括如下步骤：

S301、服务端输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口。

本申请实施例中，业务模型可为基于业务需求建立的模型，包括实现业务所需要业务元素对应的模型元素，并基于模型元素之间的关系体现对应的业务元素之间的关系。在一示例中，业务模型为领域驱动模型。本申请实施例中，对业务模型的模型类型不进行任何限定。

服务端通过页面输出的初始的业务模型可为直接打开的已经建立的业务模型，也可为通过用户输入的建模数据构建的业务模型。

服务端将业务模型通过模型元素组件实现可视化，以显示在服务端输出的至少两个页面中，使得用户通过页面所显示的模型元素组件能够直观的看到业务模型所涉及的业务、业务的类型以及业务的实现。

在业务模型为领域驱动模型的情况下，模型元素组件可如图4所示，包括以下元素对应的组件：业务领域、一个业务领域的领域服务、领域能力、扩展点等。

本申请实施例中，在业务模型为领域驱动模型的情况下，输出的页面中还包括有业务模型的模型元素组件之间的关系。如图4所示，还显示有不同业务领域之间的关系。

本申请实施例中，服务端输出的页面提供有能够接收用户对业务模型的模型元素组件的接口，以接收用于对业务模型的模型元素组件的操作。其中，接收的对模型元素组件的操作可包括：添加组件、删除组件、修改组件类型、修改组件位置等操作。

在一示例中，页面的显示如图4所示，包括：元素组件区域401和业务模型展示区域402，其中，在元素组件区域401中展示业务模型可能会涉及的元素对应的组件，在业务模型展示区域402中基于业务模型所包括的元素对应的组件展示业务模型。其中，在元素组件区域401中显示的组件包括：业务领域、一个业务领域的领域服务、领域能力、扩展点等元素的组件外，还可包括其他的组件，此时，其他的组件可通过内容为“更多”的控件获取。

本申请实施例中，不同的页面可输出至不同的客户端，使得使用不同客户端的用户能够同步地获知业务模型的结构。其中，不同的客户端可面向不同类型的客户。在一示例中，至少两个页面可包括输出至客户端A、客户端B和客户端C的页面，其中，客户端A面向的用户为业务人员，客户端B面向的用户为产品人员，客户端C面向的用户为研发人员。

S302、服务端接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面。

服务端输出至少两个页面的情况下，任一页面能够接收用户对业务模型的业务模型元素组件的操作。

客户端通过显示的页面接收用户对业务模型的模型组件的操作的情况下，生成对应接收到的操作的修改信息，并将修改信息发送至服务端。服务端接收到修改信息，基于修改信息对业务模型的模型元素组件进行调整。

在一示例中，业务模型的模型元素包括：模型元素A、模型元素B、模型元素C，页面输出有模型元素A对应的模型元素组件A、模型元素组件B、模型元素组件C；在模型元素组件A接收到删除操作的情况下，服务端接收到的修改信息指示删除模型元素组件A，此时服务端在页面中将模型元素组件A删除；在接收到添加模型元素组件D的添加操作的情况下，服务端接收到的修改信息指示添加模型元素组件D，此时，服务端在页面中添加模型元素组件D。

S303、服务端将所述修改后的业务模型输出至所述至少两个页面。

服务端基于修改信息对业务模型显示的业务模型组件修改后，将修改后的业务模型同步显示在至少两个页面，使得一个用户对业务模型的操作，能够同步显示在输出的所有页面上，实现可视化的业务模型的协同建模。

本申请实施例提供的信息处理方法，输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；将所述修改后的业务模型输出至所述至少两个页面，从而能够输出页面内容为业务模型的模型元素组件的页面，且同时输出多个针对不同用户的页面，当一个用户对业务模型的模型元素组件进行操作时，将操作结果输出至多个页面中，使得业务模型可视化的同时，保证不同用户看到的可视化业务模型的内容同步，从而降低DDD的使用门槛。

在一些实施例中，所述至少两个页面包括第二页面和第三页面，所述方法还包括：接收基于所述第二页面提供的第二接口输入的建模表格，接收基于所述第三页面提供的第三接口输入的业务描述信息；基于所述建模表格和所述业务描述信息，构建所述业务模型。

本申请实施例中，服务端可输出第二页面和第三页面至不同的客户端上，以接收产品人员输入的建模表格，以及研发人员或业务人员输入的业务描述信息，其中，研发人员输入的业务描述信息为研发人员的想法，业务人员输入的业务描述信息为业务描述。

此时，初始的业务模型为基于建模数据构建的业务模型，且建模数据包括基于第二页面接收到的建模表格和基于第三页面接收到的业务描述信息。

建模表格为基于第二页面接收到的建模数据，其中，第二页面输出至面向业务人员的客户端，使得业务人员基于第二页面输入建模表格。业务描述信息为基于第三页面接收到的建模数据，其中，第三页面为输出至面向研发人员或产品人员的客户端，使得研发人员或产品人员基于第三页面输入业务描述信息。业务描述信息包括：研发人员输入的体现研发人员对于业务模型中的元素的想法的描述信息，和/或产品人员输入的体现产品人员对应业务模型中元素的想法的业务描述。

本申请实施例中，第二页面或第三页面与第一页面可为同一页面或不同的页面，第二页面与第三页面为不同的页面。

服务在接收到建模表格和业务描述信息的情况下，将建模表格和业务描述信息作为建模数据，构建初始的业务模型。

在一些实施例中，所述方法还包括：

在所述建模表格和所述业务描述对参考对象的描述不一致的情况下，在所述第二页面和所述第三页面中分别输出提示信息；基于所述第二页面和所述第三页面中的一个或多个页面持续接收针对所述参考对象的新的描述，直到所述第二页面针对所述参考对象的描述和所述第三页面针对所述参考对象的描述一致。

参考对象为业务模型中任一元素，在不同的用户对同一元素具有不同的描述的情况下，可在输出的至少两个页面或在对参考对象具有不同描述的页面上输出提示信息，以提示当前用户，不同的用户对参考对象的描述未达成共识。

在输出提示信息后，接收对参考对象具有不同描述的用户重新输入的关于参考对象的描述，直到不同用于对该参考对象的描述达成一致，即不同用于对该参考对象达成共识。

在实际应用中，当不同用于对同一元素未达成共识的情况下，还可请第三方程序请求技术仲裁，并接收第三方程序对于该元素的描述。

本申请实施例中，当不同用于对同一元素的描述一致，即对该元素达成共识后，可将该元素对应的组件进行锁定，以提示用户当前元素为已经达成共识的元素。

在一些实施例中，基于所述建模表格、所述业务描述信息，构建所述业务模型，包括：基于所述建模表格和所述业务描述信息，确定建模数据；基于所述建模数据进行第一阶段的领域建模，得到一级建模结果；基于所述第一建模结果进行第二阶段的领域建模，得到所述业务模型；所述第一阶段的领域建模的粒度大于所述第二阶段的领域建模的粒度。

在第一阶段的领域建模中，可基于建模表格和业务描述进行领域划分、上下文定义、聚合定义、领域服务的划分，从而形成业务聚合、领域服务等粗粒度的建模产品即一级建模结果。

在一示例中，在电商场景下，划分的领域包括：订单域、库存域、商品域、商家域等。在每个域内根据业务特性，再进一步划分域，如订单域可划分为下单域、订单状态域、B端订单查询域、C端查询域等，并在划分了领域后形成限界上下文。在每个领域根据业务功能，将一个独立完整的功能形成聚合，如下单域可分为订单下单聚合、支付聚合、风控聚合等。

在第二阶段的领域建模中，基于一级建模结果定义实体、值对像、扩展点、事件、命令等，以及设计数据库、远程过程调用(Remote Procedure Call，RPC)等功能，从而确定业务模型的各个业务元素。本申请实施例中，对第一阶段的领域建模涉及的粒度和第二阶段领域建模涉及的粒度不进行具体限定。

在一些实施例中，所述方法包括：将所述业务模型分别转换为业务模型图、第一代码文件和领域建模表；将所述业务模型图输出至针对第一用户的第四页面；将所述第一代码文件输出至针对第二用户的第五页面；将所述领域建模表输出至针对第三用户的第六页面。

服务端在确定可视化的业务模型接收到修改完成的操作指示的情况下，确地当前业务建模的修改完成，并将修改完成的业务模型进行转换，其中，转换结果包括：针对第一用户的业务模型图、针对第二用户的代码文件，和第三用户的领域建模表。其中，第一用户为业务人员，使得业务人员通过业务模型图能够直观的查看所构建的业务模型；第二用户为研发人员，使得研发人员通过代码文件能够获悉所建立的业务模型；第三用户为产品人员，使得产品人员通过领域建模表能够直观的获知构建的业务模型。

服务端获得针对第一用户的业务模型图、针对第二用户的第一代码文件，和第三用户的领域建模表后，将业务模型图输出至针对第一用户的第四页面，将第一代码文件输出至针对第二用户的第五页面，将领域建模表输出至针对第三用户的第六页面。

本申请实施例中，第一代码文件包括：领域服务代码、领域驱动设计代码、代码库代码和代码分层代码，使得研发人员将第一代码文件作为模板代码进行业务扩展。

本申请实施例中，将业务模型转换为第一代码文件后，可将第一代码文件推送至代码仓库。其中，当业务模型新构建的即新工程，则可通过Git Api将代码推送到GitLab上。若业务模型为对已有的业务模型修改得到的即扩展模型，此时，需将第一代码文件与已有的业务模型的代码进行合并，并将合并后的新代码推送到远程代码仓库中。在第一代码文件与已有的业务模型的代码合并过程中，第一代码文件与已有的业务模型的代码出现冲突的情况下，需进行冲突解决。

本申请实施例中，当业务模型为新工程，可在用户业务分支下实现业务模型的代码的转换，业务模型为扩展模型，可在模型开发分支下实现业务模型的代码的转换。

在一些实施例中，所述将所述业务模型转化为所述第一代码文件，包括：对所述业务模型进行解析，生成至少一个模型表达树；一个所述模型表达树对应至少一个领域；遍历所述至少一个模型表达树，将所述模型表达树转换为对应的代码子文件；基于转换的所述代码子文件得到所述第一代码文件。

服务端将业务模型转换为第一代码文件的过程中，对业务模型的模型文件进行词法解析和语法解析，生成至少一个模型表达树，其中，词法解析是对模型的标示关键词进行解析，识别出模型的关键构成。如领域、聚合根、实体、领域服务等关键词标示(如注解等)。语法解析是对解析出的标示关键词进行语法识别，以确定各标示关键词之间的关系，得到模型表达树。

本申请实施例中，一个模型表达树对应一个代码仓库，其中，一个代码仓库对应一个或多个领域，且包括对应的领域的代码文件。一个代码仓库对应的领域可根据实际需求进行设置。

模型表达树是一个有层次关系节点构成的树，从上到下，各节点依次表述领域、聚合、领域服务、聚合根、实体等信息，这些节点相互之间有从属关系，进而形成模型树。多个遍历对象即节点的关系，是根据其相互描述的业务关系有关系的，如领域包含子域，子域多个限界上下文，聚合包含多个实体等。

在生成至少一个模型表达树后，服务端可采用图的层次遍历即广度优先算法遍历模型表达树，依次遍历模型表达树的各个节点，将模型表达树的节点转换为对应的代码段，从而将各个模型表达树依次转换成对应的代码文件即代码子文件。

本申请实施例提供的信息处理方法，能够对建立的业务模型进行自动代码生成，从而减少研发人员的工作量，提高研发人员的工作效率。

在一些实施例中，所述方法还包括：

通过抽象语法树对接收的第二代码文件进行解析，得到所述第二代码文件的用于建模的模型标识；所述第二代码文件是接收的对所述第一代码文件进行修改后的代码文件；基于所述模型标识，生成至少两个局部模型，并确定所述至少两个局部模型之间的依赖关系；基于所述依赖关系将所述两个局部模型，整合为所述第二文件代码对应的目标业务模型。

服务端在输出第一代码文件后，可接收到研发人员对第一代码文件进行修改后得到的第二代码文件，其中，第二代码文件为第一代码文件进行业务扩展或业务修改的代码文件。

本申请实施例中，不同的第一代码文件可通过代码文件标识被研发人员调用，且在存在业务扩展需求或业务修改需求时，研发人员可直接对第一代码文件进行修改，得到表征业务需求的第二代码文件，并将第二代码文件提交至服务端，此时服务端接收到第二代码文件。

服务端通过词法解析、语法解析生成第二代码文件的抽象语法树(abstractsyntax code，AST)，并基于AST确定第二代码文件的关键环节，以提取进行领域建模的模型标识即模型元数据，其中，模型标识可为可视化领域建模定义的注解或标记。本申请实施例中，对服务端解析第二代码文件所采用的技术不进行任何限定。

服务端基于提取的模型元数据，生成针对单个代码子文件的局部模型，并建立局部模型之间的依赖关系，其中，一个代码子文件表征一个局部模型，并基于局部模型之间的依赖关系对建立的局部模型进行整合，得到目标业务模型。

本申请实施例中，能够基对基于第一代码文件的扩展得到第二代码文件进行反解析，实现第一代码文件的扩展性。

在一些实施例中，所述方法还包括：生成所述目标业务模型对应的第三代码文件；基于所述第三代码文件替换所述第二代码文件。

服务端在生成目标业务模型后，可将目标业务模型转换为第三代码文件，这里，将目标业务模型转换为第三代码文件的过程可参照业务模型转换为第一代码文件的过程，这里不再赘述。

服务端得到第三代码文件后，将接收到的第二代码文件替换为第三代码文件，并建立目标业务模型和第三代码文件之间的关联关系。本申请实施例中，删除接收到的第二代码文件，使用新模型生成的代码文件，使得模型代码和模型是匹配的。

下面，对本申请实施例提供的信息处理方法进行进一步说明。

随着互联网的深入发展，软件所承载的通用业务范围和逻辑越来越复杂。企业面临的ToB业务扩展，面临着定制化、差异化严重的问题。作为软件开发任务、产品设计人员、业务运营，如何应对复杂的业务逻辑、大量差异化的业务，是每一个软件参与者需要面临的迫切问题。DDD作为一种软件思想，用于解决复杂业务的建模，来指导繁杂的业务开发。但是DDD对于新手门槛高，产品与业务运营难参与到建模，难以统一语言。建模之后，需要重新开发代码，开发成本高。DDD实践中常出现建模难以持续，业务知识难以沉淀。

相关技术中，软件开发模式为：业务提需求产出商业需求文档(BusinessRequiment Document，BRD)，产品进行产品设计产出产品需求文档(Production RequimentDocument，PRD)，研发和产品进行评审PRD，需求排期，最终研发开发代码。对于复杂场景的软件开发，采用失血或贫血模型，使用模型-视图-控制器(Model-View-Controller，MVC)模型来开发代码。其中，MVC模型的服务(Service)层杂糅有丰富的逻辑，从而表达丰富的业务知识，完成业务编排、对象转换、业务逻辑处理、持久化资源访问、事务控制等。

上述软件开发模式业务耦合严重。在业务简单时，仅需CRUD便能满足需求。但伴随着业务的日渐复杂，系统也变得越来越复杂，软件模块之间彼此高度关联，甚至研发人员很难说明具体模型的作用和设计意图。在面临新需求的情况下，研发人员需要大量时间评估和推演，如何修改老代码，才能满足业务的需求。因此，软件变得难以维护，需求被大量拖延，使得花费大量的时间，且工作效率低。

采用大量的贫血模型，只有获取(get)/设置(set)方法。对象本身的业务逻辑，被杂糅在服务(service)层中，业务知识与对象脱离，用着面向对象设计(Object-OrientedDesign，OOD)的语言做着面向对象编程(Object Oriented Programming，OOP)的事情。对象在服务(service)创建，并在整个流程中都能修改对象，并将业务知识散落在各个角落，难以形成高内聚低耦合的业务模型与业务知识。在一示例中，在下单场景中，下单是一个服务，下单会包含查询商品信息、查询商品的价格信息、计算商品的促销信息、计算商品的运费信息、计算商品使用的优惠券信息。在下单中，会创建很多的对象，其中一个对象是商品对象，而计算商品的促销价格、运费价格、使用的优惠券价格后，会在service分别设置商品的对应价格信息。

建模只有研发参与，产品和业务运营难于参与。业务需求在从业务、产品、研发传递的过程中，易出现信息丢失或出现理解偏差，易造成反复沟通，甚至会推翻代码重新开发。

虽然DDD能快速适应复杂业务的发展，建模能形成业务知识的积淀。然而使用DDD建模和开发的门槛高，产品和运行难于参与进来，往往是主要由研发自己建模。建模之后语义不明晰，产品和运行难于看懂。建模之后又需开发DDD框架代码。后期开发时，已有的建模结果难以持续建模，甚至出现一次建模，后期又变成传统的MVC与贫血开发模式。

本申请实施例中，针对业务发展复杂快速、定制化需求多的场景，采用DDD来解决业务的复杂和差异性问题时，为降低DDD建模门槛和成本，通过标准化的DDD模型设计了DDD可视化建模平台，为建模提供标准化的建模支持和帮助，能够让业务运营、产品参与到业务建模中，通过协同建模来保证业务理解的无偏差，统一业务语言。并通过代码生成技术和反向解析技术，得到包括代码、业务模型图和领域建模表的业务建模结果。业务建模结果沉淀在平台，后期需求变动时修改模型，形成最新的建模结果和代码，降低了建模的门槛，增加了沟通效率，减少了业务维护维护成本，提高了开发效能。且业务建模结果作为知识资产，方便内外部业务交流。

本申请实施例提供的DDD可视化建模平台可具备以下功能：

业务建模平台接收业务输入的需求、产品输入的文档、研发输入的想法等内容，使得业务、产品、研发协同建模，通过可视化建模平台搭建业务知识、业务模型，达成一致的业务语言，最终通过一次建模输出多份输出结果：针对研发的框架代码、针对产品的建模表、以及针对业务的业务模型等，从而形成直观、高效、标准、易扩展的建模结果。

业务建模过程可如图5所示，包括以下三个阶段：输入素材501、可视化业务建模502和输出建模结果503。

在输入素材501，业务、产品、研发协同建模，输入的素材包括：业务504输入的建模表格、研发505输入的想法以及产品506输入的业务描述，，输入建模需要的素材，其中，业务504、研发505和产品506可通过线下讨论或在线协同方式输入素材。

在可视化业务建模502，可视化页面显示的内容可包括图4所示的内容：业务模型的模型元素组件和业务模型，还可包括：操作控件，以执行对应的操作，显示的操作控件可包括：触发工具栏显示的工具栏控件、触发建立新业务模型的新建控件、触发导入业务模型的导入控件，触发业务模型分享的分享控件、触发保存业务模型的保存控件、触发业务模型发布的发布控件等。其中，可视化页面中显示的初始的业务模型可为输入素材501阶段输入的素材形成的业务模型，使得用户可基于模型元素组件对初始显示的业务模型进行修改，得到需要的业务模型。在可视化业务建模502阶段完成后，执行输出建模结果503。

其中，可视化业务建模502输出的页面可由业务建模平台生成。

在输出建模结果503，输出建模结果，输出的建模结果包括：输出业务模型图至业务504，输出领域服务模板代码、DDD模板代码、代码库模板代码、代码分层模块代码至研发505，输出领域建模表至产品506。

在图5所示的可视化建模过程中，可视化建模底层细节如图6所示，业务建模平台601分别执行建模视图选择6011、领域粗建模6012、领域细建模6013，其中，在建模视图选择6011确定的内容包括：建模素材、建模组件、业务术语、术语关系、术语单元和视图拖拽。领域粗建模6012确定的内容包括：界限上下文、上下文关系、聚合服务、领域服务、流程编排等。领域细建模6013确定的内容包括：聚合根、实体、值对象、事件、命令等。输出的建模结果包括：业务模型图、生成的代码和领域建模表，其中，生成的代码包括：不同类型的代码库、数据库/RPC代码、领域驱动代码、代码分层模块代码、测试代码等，其中，不同类型的代码库对应不同的领域。

在一示例中，对于下单场景，建模过程的模型元素组件包括：商品信息限界上下文、库存预占限界上下文、风控限界上下文、用户限界上下文等。不同用户可根据业务理解，划分出业务限界上下文，并在线基于模型元素组件进行业务模型的模型图。

业务建模平台进行领域驱动建模，先进行业务知识的理解和统一，通过头脑风暴，划分领域和限界上下文、区分聚合、定义领域服务等。

业务建模平台提供在可视化组件，可使得用户在线拖拽可视化的组件，如领域边界、聚合根、领域服务、扩展点等，将头脑风暴的中间结论和最终共识反应在可视化的图像中。

业务建模平台最终输出的结果包括：业务模型图、框架开发和领域建模表，其中，业务模型图能够方便业务查看已有业务知识；框架开发能够加速研发开发效率；领域建模表能够方便产品了解模型，形成业务模型沉淀。

业务建模平台支持已有业务模型的导入，通过excel或已有的建模模型图，生成可视化的建模结果，同时支持在线协同建模，支持跨地域的业务建模，建模结果可保存在云平台，方便后期二次建模，以及业务知识的沉淀。

本申请实施例提供的业务建模平台的可视化建模技术包括：

S1、业务、产品、研发协同建模，包括在线远程协同建模，或在同一个物理地点进行建模会话。

S2、根据项目背景、需求知识，通过沟通对其业务知识，业务功能，区分核心功能、支撑功能。并在各个人员中统一语言，形成共识。若对业务理解存在不一致，可通过投票或通过技术仲裁，形成业务共识，统一业务术语、单元、功能等。用户可选择已有的模型，或者建模样例，来进行复用，来简化建模成本。本申请实施例中，技术仲裁可为邀请部门级别或更多一级的架构师团队、业务专家，进行业务建模的评审，以更高一级的视角，参与投票与决策。

S3、划分领域边界形成限界上下文和领域关系，形成业务聚合、领域服务等粗粒度的建模产品。在这个过程中会划分成领域边界，如电商场景下，划分的领域包括：订单域、库存域、商品域、商家域等。在每个域内根据业务特性，再进一步划分域，如订单域可划分为下单域、订单状态域、B端订单查询域、C端查询域等，并在划分了领域后形成限界上下文。在每个领域根据业务功能，将一个独立完整的功能形成聚合，如下单域可分为订单下单聚合、支付聚合、风控聚合等。聚合对外的能力，只能通过领域服务来对外暴露，保证域内的功能稳定，外界不受域内的影响。

S4、产品和业务会参与领域划分、上下文定义、聚合定义、领域服务的设计，以及流程粗粒度的编排。形成共识后，研发继续进行细粒度的建模，定义实体、值对像、扩展点、事件、命令等，以及设计数据库、RPC等功能。

S5、在第S3步的基础上，对聚合内的信息进行划分，抽取业务特性，将隐形的概念显性化、将隐形的语义显性化、将隐形的逻辑显性化，形成领域实体，值对像。实体是一个有生命周期变化的数据，有一个唯一的id能够标示实体。值对像是相对当前聚合，一个稳定无变化的数据，相当于数据的一个快照。一个对象是实体或值对像，需要根据业务上下文来确定，如商品在下单聚合中是一个值对像，但在商品域里是一个聚合根或实体。

S6、对业务的支撑功能可通过领域服务来对外暴露。其中，支撑功能包括扩展功能和通用功能，为响应业务的定制化、差异化、个性化，需要对领域服务设计扩展点。后期有定制化需求时，优先实现扩展点，来满足业务的定制。领域复用面向业务的复用的定制，扩展到面向差异功能。其中，扩展点包括：垂直业务的扩展点(单个业务方使用的独立的扩展点)、水平业务的扩展点(可供多个业务模型使用的扩展点，可供多个垂直业务方共享的)。当水平业务的扩展点扩展的功能命中多个业务场景，能响应多类水平业务时，可考虑将扩展点功能升级成水平的通用功能。

S7、设计业务事件。领域事件来接耦不同领域的系统的关系，以及模块。如下单通知其他系统，可通过领域事件来通知。事件分为同步事件和异步事件。

这里，多个业务领域之间的通信，可通过事件通知的机制，将业务领域解耦。如下单后，进行下单通知发送邮件或短信，通过领域事件，有下单子域发送领域事件，由下单通知子域进行实际的通知。

S8、在业务模型确定的基础上，可保存业务模型，供后期二次建模。可发布模型，形成框架代码、领域建模表等。框架代码包括：不同类型的代码库、标准的分层结构、领域驱动代码、测试代码等。

本申请实施例提供的业务建模平台的结构如图7所示，包括：可视化建模前台701、模型代码组件702、模型中间价703、底层存储层704。

可视化建模前台701，包括前台视图和Restful接口层前台视图7011由VUE、Html等技术实现，

可视化建模前台701提供以下接口：模型建模7011、模型共享7012、模型复制7013、模型分享7014、模型发布7015等接口，以触发对应的功能，模型建模是通过视图组件标示不同的领域模型组件，如限界上下文、聚合根、实体等，通过这些组件来构成业务模型。

模型共享用于将已有模型通过云共享的方式发送给参与者，来共同协同建模。模型复制利用已有的建模结果，在模型空间通过关键词找到合适的业务模型，并通过复制再在这个业务模型上二次建模，形成当前业务的建模结果。模型分享将建模结果以只读的形式发送给其他人。模型发布将会触发业务模型向模型结果的转换。模型建模前台使用前后端分离架构，由视图层和Restful接口层构成。

模型代码组件702包括：模型语法解析器7021、模型代码器7022、代码推送器7023、模型语义解析器7024、模型访问器7025、和模型树算法7026等，用于完成核心的模型解析，模型向代码的转换，代码冲突后的合并，以及模型合并保存，合并后代码的提交等。经过模型校验、语法解析、模型语义解析后，会将模型表达成模型树。对应模型代码组件，最核心的概念是模型树，将业务模型通过多叉树的形式来表达组织起来。模型树有多种代码转换算法，针对反向由代码生成模型或合并模型的场景，需要实现反向模型解析器，将代码转换成java的AST模型(如利用JavaParser)，再用AST语法规则来解析出建模关键词，生成建模模型树，或与当前建模模型树进行两个树的合并。针对Go、Python语言也是类似。如果无反向由代码生成模型的需求，可使用FreeMarker定义模版，模型代码器在运行时将代码转换加工成代码。模型访问器是建模模型的访问API，提供模型查询、模型保存、模型合并的访问接口，具体功能是否模型中间层提供。

模型中间件703，将模型的基础功能封装，形成稳定的模型能力，上层无需关系模型底层的细节。模型中间件703提供RPC接口供上层来访问，提供的接口包括有：模型查询接口7033、模型合并接口7032、模型保存接口7033、模型信息修改接口7034、模型复制接口7035、模型共享接口7036等。模型中间件提供的接口，可供模型代码组件、模型建模前台使用。

底层存储层704、作为底层数据存储的资源，共享业务提供基础支持。底层存储层704包含数据库7041、Redis7042、云文档共享组件7043、视频语音基础设施7044、GitLab7045。数据库作为永久存储，存储模型空间、模型数据、模型权限等。Redis存储热点数据，在访问量大时使用，如果前期并发量不大时不用Redis。云文档共享组件提供的文档在线编辑功能。视频语音基础设施提供远程协同建模，是视频语音功能加持。云文档、视频语音功能作为建模平台的非核心领域，使用基础技术团队提供的云文档、视频语音能力。GitLab用于存储代码，其中，代码仓库、合并采用Git来实现合并，最后代码存储在GitLab。

下面，对业务模型生成代码和代码转换成业务模型的过程进行描述。

可视化建模生成业务模型后，可通过自动生成代码，减少建模后研发重新开发领域代码的成本，降低由领域建模模型到领域驱动代码的难度，达到model as code(模型即代码)的效果。本申请实施例中，基于业务模型生成代码的过程可如图8所示，包括：

S801、接收代码生成请求；

用户在管理端建模，建模完毕后，选择发布代码，触发代码生成，服务端接收到代码生成请求。

S802、根据用户账号切换至对应的模型开发(dev-model)分支。

服务端接收到代码生成请求的情况下，判断当前项目是否为新工程，若项目为新工程，会用开发者账号新建代码仓库，并切换到dev-model(专门用于存储模型代码的分支，只有模型或框架的代码，无具体业务逻辑部分)。若项目为老工程，则切换到对应的dev-model分支。

S803、根据业务模型生成模型代码。

对模型文件进行词法解析和语法解析，生成模型表达树。采用图的层次遍历即广度优先算法遍历模型表达树。依次遍历模型表达树，将模型表达树依次转换成对应的单个代码文件即代码子文件。

这里，词法解析是对模型的标示关键词进行解析，识别出模型的关键构成。如领域、聚合根、实体、领域服务等关键词标示(如注解等)。

其中，模型表达树是一个有层次关系的树，从上到下，依次表述领域、聚合、领域服务、聚合根、实体等信息，他们相互之间有从属关系，进而形成模型树。多个遍历对象的关系，是根据其相互描述的业务关系有关系的，如领域包含子域，子域多个限界上下文，聚合包含多个实体等。

S804、将代码推送至远程代码仓库。

若项目为新工程，通过Git Api将代码推送到GitLab上，若为已有代码，模型的最新代码在dev-model，需要将dev-model合并到用户业务分支，若合并的过程出现合并冲突，需要人工解决冲突。解决冲突有本地合并和在线浏览器合并两种方式，调用Git Api将解决冲突后的最新代码推送到远程代码仓库。其中，本地合并是在开发本地的电脑上合并，在线合并是在在线代码仓库管理平台上进行合并。

本申请实施例中建模系统提供两个分支：用户业务分支和dev-model，用户业务分支泛指日常的需求、项目的开发分支，dev-model只包含模型的框架代码，模型变动后对应的框架代码维护到dev-model分支。再将dev-model的分支的代码合并到业务分支，领域建模的框架代码便和业务代码合并了。

图8提供的基于业务模型生成代码的过程还可如为图9所示的：

S901、判断业务模式是否为新工程。

如果是，执行S9021，如果不是，执行S9022。

S9021、新建仓库并拉取新模型开发分支。

S9022、切换到模型开发分支。

S903、对业务模型进行词法解析。

S904、对词法解析结果进行语法解析，得到模型表达树。

S905、广度优先遍历模型表达树。

S906、按照模型表达树的节点生成单个代码文件。

S907、判断业务模式是否为新工程。

如果是，执行S9081，如果不是，执行S9082。

S9081、提交模型代码到本地模型开发分支。

S9082、合并模型代码分支到用户业务代码分支。

S9083、判断是否有冲突？

如果没有，则执行S9089，如果有，则执行S9084。

S9084/发送邮件以通知人工合并.

在冲突解决后执行S909。

S909、调用Git API提交代码并推送到远程代码库。

本申请实施例提供的业务建模平台，通过建模的模型标示如注解，可利用语法技术逆向生成模型，把代码转换成业务知识资产，便于后期模型的后期维护和业务积累。用于解决已有系统，生成建模模型的问题，以及首次建模后，研发在代码侧进行开发，却未在建模平台同步维护模型的场景。通过逆向生成模型的技术，方便模型后期的维护，以及提供研发建模的效率和便捷。本申请实施例中，基于业务代码生成业务模型的过程可如图10所示，包括：

S1001、提取业务模型的模型标识。

通过编程语言AST，解析代码的关键环节，提取领域建模的模型标识。模型标识为可视化领域建模定义的注解或标记。针对Java、Go、Python等，通过AST解析技术解析代码，Java可用JavaParser。

S1002、基于提取的模型生成局部模型。

遍历代码文件，对提取的模型元数据进行词法解析、语法解析、模型生成，生成针对单个代码文件的局部模型，并建立局部模型的依赖关系。

S1003、基于生成的局部模型，确定目标业务模型的模型文件。

继续遍历代码文件，最终将局部的模型，生成整体的业务模型的模型文件。

S1004、保存目标业务模型的模型文件。

保存最新的模型文件，便于后期通过模型历史，来查询模型变化情况，作为一种业务变化的资产积累下来。

S1005、删除原代码文件，并生成新的代码文件。

删除模型代码dev-model的内容，用新模型生成模型代码，这样模型代码和模型图是匹配的。

S1006、将新的模型代码提交到远程代码仓库。

这里，反向由代码生成模型的场景，以代码里包含的模型为准，通过模型解析生成模型，再由模型生成模型代码。如果要合并两个模型，逻辑是复杂且困难的，要进行两个模型的比较，所以这里以代码的模型为准，删除原来的dev-model的代码，将新生成的模型代码分支提交到dev-model分支。从而保证模型、代码是一致的。

如图10所示基于业务代码生成业务模型的过程还可如图11所示，包括：

S1101、遍历代码文件，生成AST。

S1102、通过AST解析建模文件注解及标识.

S1103、生成单个文件对应的模型。

S1104、建立模型依赖。

S1105、代码文件是否解析完毕？

如果解析完毕，则执行S1106，否则执行S1102。

S1106、生成最新整体模型文件。

S1107、保存新模型。

S1108、形成变动历史方便后期查询。

S1109、删除模型开发分支的代码。

S1110、更新新模型生成新的模型代码。

S1111、提交新的模型代码到本地及远程仓库。

图12为本申请实施例的一种信息处理装置的结构示意图，如图12所示，信息处理装置1200包括：

第一输出模块1201，用于输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；

接收模块1202，用于接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；

所述第一输出模块1203，还用于将所述修改后的业务模型输出至所述至少两个页面。

在一些实施例中，装置1200还包括：

接收模块，用于接收基于所述第二页面提供的第二接口输入的建模表格，

所述接收模块，还用于接收基于所述第三页面提供的第三接口输入的业务描述；

构建模块，用于基于所述建模表格和所述业务描述信息，构建所述业务模型。

在一些实施例中，装置1200还包括：

提示模块，用于在所述建模表格和所述业务描述对参考对象的描述不一致的情况下，在所述第二页面和所述第三页面中分别输出提示信息；

共识模块，用于基于所述第二页面和所述第三页面中的一个或多个页面持续接收针对所述参考对象的新的描述，直到所述第二页面针对所述参考对象的描述和所述第三页面针对所述参考对象的描述一致。

在一些实施例中，构建模块，还用于：

基于所述建模表格和所述业务描述信息，确定建模数据；

基于所述建模数据进行第一阶段的领域建模，得到一级建模结果；

基于所述第一建模结果进行第二阶段的领域建模，得到所述业务模型；所述第一阶段的领域建模的粒度大于所述第二阶段的领域建模的粒度。

在一些实施例中，装置1200还包括：

转换模块，用于将所述业务模型分别转换为业务模型图、第一代码文件和领域建模表；

第二输出模块，用于将所述业务模型图输出至针对第一用户的第四页面；

所述第二输出模块，还用于将所述第一代码文件输出至针对第二用户的第五页面；

所述第二输出模块，还用于将所述领域建模表输出至针对第三用户的第六页面。

在一些实施例中，转换模块，还用于：

对所述业务模型进行解析，生成至少一个模型表达树；一个所述模型表达树对应至少一个领域；

遍历所述至少一个模型表达树，将所述模型表达树转换为对应的代码子文件；

基于转换的所述代码子文件得到所述第一代码文件。

在一些实施例中，装置1200还包括：反解析模块，用于：

对接收的第二代码文件进行解析，得到所述第二代码文件的用于建模的模型标识；所述第二代码文件是接收的对所述第一代码文件进行修改后的代码文件；

基于所述模型标识，生成至少两个局部模型，并确定所述至少两个局部模型之间的依赖关系；

基于所述依赖关系将所述两个局部模型，整合为所述第二文件代码对应的目标业务模型。

在一些实施例中，装置1200还包括：替换模块，用于：

生成所述第三业务模型对应的第三代码文件；

基于所述第三代码文件替换所述第二代码文件。

以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请系统实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的信息处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)运行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

本申请实施例还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器运行所述计算机程序时，实现上述服务端的信息处理方法中的步骤。

对应地，本申请实施例提供一种存储介质，也就是计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器运行时，实现上述实施例中服务端提供的信息处理方法。

这里需要指出的是：以上存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，图13为本申请实施例电子设备的(服务端)一种硬件实体示意图，如图13所示，所述电子设备1300包括：一个处理器1301、至少一个通信总线1302、至少一个外部通信接口1304和存储器1305。其中，通信总线1302配置为实现这些组件之间的连接通信。在一示例中，电子设备1300还包括：用户接口1303、其中，用户接口1303可以包括显示屏，外部通信接口1304可以包括标准的有线接口和无线接口。

存储器1305配置为存储由处理器1301可运行的指令和应用，还可以缓存待处理器1301以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种信息处理方法，其特征在于，所述方法包括：

输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；

接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；

将所述修改后的业务模型输出至所述至少两个页面。

2.根据权利要求1所述的方法，其特征在于，所述至少两个页面包括第二页面和第三页面，所述方法还包括：

接收基于所述第二页面提供的第二接口输入的建模表格，

接收基于所述第三页面提供的第三接口输入的业务描述；

基于所述建模表格和所述业务描述信息，构建所述业务模型。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

在所述建模表格和所述业务描述对参考对象的描述不一致的情况下，在所述第二页面和所述第三页面中分别输出提示信息；

基于所述第二页面和所述第三页面中的一个或多个页面持续接收针对所述参考对象的新的描述，直到所述第二页面针对所述参考对象的描述和所述第三页面针对所述参考对象的描述一致。

4.根据权利要求2所述的方法，其中，所述基于所述建模表格、所述业务描述信息，构建所述业务模型，包括：

基于所述建模表格和所述业务描述信息，确定建模数据；

基于所述建模数据进行第一阶段的领域建模，得到一级建模结果；

基于所述第一建模结果进行第二阶段的领域建模，得到所述业务模型；所述第一阶段的领域建模的粒度大于所述第二阶段的领域建模的粒度。

5.根据权利要求1所述的方法，其特征在于，所述方法包括：

将所述业务模型分别转换为业务模型图、第一代码文件和领域建模表；

将所述业务模型图输出至针对第一用户的第四页面；

将所述第一代码文件输出至针对第二用户的第五页面；

将所述领域建模表输出至针对第三用户的第六页面。

6.根据权利要求5所述的方法，其特征在于，所述将所述业务模型转化为第一代码文件，包括：

对所述业务模型进行解析，生成至少一个模型表达树；一个所述模型表达树对应至少一个领域；

遍历所述至少一个模型表达树，将所述模型表达树转换为对应的代码子文件；

基于转换的所述代码子文件得到所述第一代码文件。

7.根据权利要求5所述的方法，其特征在于，所述方法还包括：

对接收的第二代码文件进行解析，得到所述第二代码文件的用于建模的模型标识；所述第二代码文件是接收的对所述第一代码文件进行修改后的代码文件；

基于所述模型标识，生成至少两个局部模型，并确定所述至少两个局部模型之间的依赖关系；

基于所述依赖关系将所述两个局部模型，整合为所述第二文件代码对应的目标业务模型。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

生成所述目标业务模型对应的第三代码文件；

基于所述第三代码文件替换所述第二代码文件。

9.一种信息处理装置，其特征在于，所述装置包括：

第一输出模块，用于输出至少两个页面，所述至少两个页面中每一页面的显示包括：业务模型的模型元素组件，所述至少两个页面中每一所述页面提供有用于接收针对所述模型元素组件的接口；

接收模块，用于接收到通过第一页面的第一接口输入的针对所述模型元素组件的修改信息，通过所述修改信息对所述模型元素组件进行修改，得到修改后的业务模型，所述第一页面为所述至少两个页面中任一页面；

所述第一输出模块，还用于将所述修改后的业务模型输出至所述至少两个页面。

10.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时，实现权利要求1至8任一项所述信息处理方法中的步骤。

11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器运行时，实现权利要求1至8任一项所述的信息处理方法。

Images