星型结构的通用业务模型的制作方法
【技术领域】：
[0001] 本发明涉及到的技术领域是软件面向对象开发模式中的一种，即领域模型驱动开 发方式。本发明设计了一种星型结构的通用模型，应用到领域模型驱动开发方式中，实现了 领域模型的标准化，并且提供了相关的框架，对数据的结构和对数据模型的处理方式实现 了通用化，标准化，大大降低了由于在以往的开发过程中，模型多样化带来的多重处理的问 题，降低了建模的难度，提高了建模的效率。
【背景技术】：
[0002] 传统的面向对象的开发方式，包含了以下几个开发过程，1.需求收集，2.需求分 析，3.概要设计，4,详细设计，5.编码实现。在这样过程中，产生的模型有：1.需求用例模 型，2.设计模型。而领域驱动开发方式（DDD:DomainDrivenDesign)的引入[1]，在需求 用例模型和设计模型中引入了"领域模型"的概念。产生了一个各个部门都能够理解的通用 模型，更有利于开发部门和客户的交流，使得面向对象的软件开发更加接近实际业务流程， 技术模型更接近于业务需求的各个模块。
[0003]但实际上，领域模型驱动在实现的过程中，由于不同业务的流程的差异，领域模型 的具体构成也是千差万别。实际开发中，领域模型直接转换成面向对象的基础类，进行处理 的开发方式存在着一些问题：面向对象的模型普遍是只有二维结构的简单数据模型，为了 基于它构建出复杂的数据模型，必然使得开发人员大部分的精力放在了维护不同的模型的 结构，处理不同结构的数据上来，由于不同业务模型的差异，对数据的维护和处理方式也差 别较大，不同的模型，要重新制定特定的数据处理方式。这样的作法，一方面浪费了开发人 员的精力，使得模型的开发效率低下，另一方面，各个模型服务层的类往往也集中了大量这 样的不同的数据维护性的方法，造成数据结构层"肥大"，难以维护。
[0004]经过长期的观察和经验积累，我们发现，绝大部分的领域模型之间的建模形式，可 以由星型拓扑结构来表示，即每个模型，由一个且唯一的根节点来描述该模型的基本信息。 根节点下面，有多层的子节点来描述和模型相关的附加性信息。
[0005]我们将这样一个可以独立出来的，可以由星型结构描述的数据模型单元，称为一 个服务实体（ServiceEntity)。它上面的每一个节点，将对应面向对象语言的一个二维的 简单数据类。称为一个服务实体节点（ServiceEntitynode)。
[0006]除了提出星型结构的通用业务模型的概念。本发明还采用了JAVA面向对象的编 程语言，构建了基于JAVA平台的基本服务实体框架，该框架用于支持服务实体，即星型通 用业务模型的快速建模和维护。
【发明内容】
：
[0007]为了解决领域模型驱动建模中，不同形式的领域模型建模效率低下、难以维护的 问题，我们提出了一种星型拓扑结构的通用模型，称为：服务实体（ServiceEntity)。对业 务模型的建模，我们统一地使用星型结构的数据模型来表示，即有一个唯一的根节点描述 模型的基本信息，其它信息，由一对一或者一对多子节点来描述。通用的模型结构，一方面 数据结构统一化，另一方面对数据的处理也实现了通用化，在这种情况下，服务实体的结构 维护，包括实体内部各个节点的关系，以及实体间的关系维护，均由框架实现。
[0008] 这样一个可以独立出来的，由星型结构描述的业务单元，称为服务实体（Service Entity)。服务实体的每一个节点，将对应面向对象语言的一个简单数据类。称为一个服务 实体节点（ServiceEntitynode)。
[0009] 节点的类型有下面几种：
[0010] 1.根节点：根节点用于描述服务实体的基本属性，且和服务实体本身呈现1比1 的对应关系，比如模型的标识性信息，如编号，名称等，或者类似于凭证的优先级别，生成时 间等。
[0011] 2.子节点：用于描述服务实体的非基本信息，即附属性质的信息，和服务实体本 身呈现1比1或者1对多的关系，比如销售订单中，包含的销售商品的信息。和销售订单呈 现1对多的关系。
[0012] 3.引用节点：当一个服务实体需要引用到外部服务实体，基本的信息由外部实体 提供，本服务实体仅仅提供和本服务实体业务相关的信息，这种引用关系中，需要建立引用 型节点。如销售订单中，商品销售信息将会引用到"商品"这个独立于销售订单之外的服务 实体，销售订单中，销售商品节点中包含了销售本身相关的信息，如销售数量，销售价格，但 是商品本身的信息来自于对商品这个服务节点的引用。
[0013] 下面通过一个实际的例子，描述通过服务实体，实现"销售订单"的建模过程。
[0014] 一个销售订单的模型中，和订单本身密切相关的基本信息包括订单号，订单生成 日期，经办人，优先级别等等。这些基本信息我们定义为订单的根节点信息。销售订单还包 括了"销售商品"的信息，这些信息和订单呈现1对多的关系，即一个销售订单可以包含多 条销售商品信息，我们定义为子节点"销售商品"。而"销售商品"节点应该是引用型节点， 因为销售商品中的商品自身信息应该是来自"商品"这个在销售订单外的独立的模型，比如 商品的名称，商品的特点等等，"销售商品"引用自"商品"模型，"销售商品"自身包含的是 和订单中销售活动相关的信息，比如用户购买数量，购买单位等等。
[0015] 另一方面，销售订单还包括了参与方的信息，常用的销售订单包含了两个参与方， 买方和买方，参与方的子节点包括的信息，应该有：参与方，主要联系人姓名。联系人电话， 电子邮件，参与方角色（比如买方，卖方，供货方，提货方，付款方等等）。
[0016] 基于以上信息我们可以构建这样星型的"销售订单"数据模型，该模型的结构图， 请参考【附图说明】中的图2。
[0017] 在定义好了数据模型后，会根据实际业务场景，生成数据模型的实例。假设有这样 的业务场景：电子科技公司（TechA)作为卖方，对服务咨询公司：ServiceB达成了一项销售 订单，这个销售订单中包含了 3类商品：10台手机，3台电脑，5台摄像机。同时，他销售订单 号：SA20130203001，优先级别：A，生成时间：2013. 02. 03,创建人：王强，总价格：40000元。
[0018] 根据上面的服务实体模型，我们可以得到运行时的数据模型实例，其结构图参考
【附图说明】的图3。
[0019]围绕着服务实体的建模，我们提供了统一的基本化框架。一方面支持服务实体的 快速建模和通用数据处理，同时，框架为开发者自定义功能的开发，提供了规范，使得开发 人员在自定义功能时，代码、模块更加规范，更利于维护。
[0020] 基本化框架的基本构成，第一部分是模型定义部分，S卩服务实体的每个节点的定 义。通过定义JAVA的简单数据量类，继承框架提供的基类ServiceEntityNode。同时，用 配置类ConfigureProxy来描述模型的构成，数据结构。第三部分是数据访问类DA0类，同 理，继承框架的父类ServiceEntityDAO。可以通过配置和数据库链接。实现服务实体中所 有节点和数据库的数据交换。第四部分是服务层，或者逻辑管理层。为服务实体，提供基本 的服务：
[0021] 服务实体的数据生成：包括根节点生成和子节点的生成。
[0022] 数据更新服务：能够接受从表现层传入的服务实体数据，并且和后台的服务实体 数据进行比较，对每个节点的数据进行更新，新增，删除操作，并且记录相关日志。
[0023] 引用节点服务，构建新的引用节点，通过引用节点找到被引用的目标节点。
[0024] 动态查询服务，通过输入任意节点的属性值，进行匹配查找，也可以对任意输入查 询值，进行任意节点和属性的自由匹配查找。
[0025] 系统基本框架的结构图请参考【附图说明】中的图4。
【附图说明】
[0026] 图1星型结构通用数据模型的示意图
[0027] 图2描述了一个简单的"销售订单"的服务实体模型的星型结构。
[0028] 图3描述了在上一章的业务场