CBF Studio业务建模示例（3）-服务应用模型设计

服务应用需求分析

---

  实际上这个步骤属于应用模型范畴，在数据模型设计完成后，需要开始进行业务模型设计了，然后才是应用模型设计。但是服务模型是可以先行设计的，为的是对业务数据的访问和维护做标准化任务支撑，这些服务应用设计是可以直接在业务模型中复用的，间接的支持业务模型设计做。
  因此服务应用模型设计一开始不需要很复杂，仅针对既有的数据模型做CRUD操作即可。以个人客户基本信息的创建、查询和更新为例分析如何设计服务接口，以及基本的服务处理逻辑。

服务名称	请求接口	应答接口	功能说明
创建个人客户基本信息	1.创建人标识；2.个人客户基本信息		创建人标识用于登记客户信息开立的客户经理信息，需要做校验；个人客户基本信息中唯一标识客户编号由本服务创建，其他非唯一标识的必输项需要做校验
查询个人客户基本信息	客户编号	个人客户基本信息	仅当客户编号不为空的情况下执行查询逻辑
维护个人客户基本信息	1.维护人标识；2.个人客户基本信息；3.维护类型（实例组：更新/删除）	个人客户基本信息	维护人标识用于登记客户信息变更的客户经理信息，须交验；个人客户基本信息必须是已开立的信息才能维护，且客户编号不允许变更

  需要注意的是变更个人客户基本信息的时候是需要产生一条历史记录的，为了化简演示过程在前一篇数据模型设计中并未提到，读者可自行补充。

客户编号生成接口

---

  在创建个人客户基本信息的时候需要由系统生成唯一的客户编号标识，且需要满足业务规则要求。为了化简演示，选择以后台服务的方式来生成客户编号并返回给调用方。当然还可以选择在客户编号的数据模型中添加编号生成方法，或者采用系统对象类设计来提供，方案很多，读者自行选择。
  客户编号生成服务定义如下：

  接下来需要配置客户编号的配置，在企业资源服务的部署目录下找到名为“Eap.ShareResource.config”的配置文件，打开并新增一行：

  配置中可以看到客户编号从0开始，共13位，每次递增，不必担心序号重复问题，这些并发问题都由企业资源服务系统来保证。但是这和客户号的业务规则不同，因为是化简的示意。然后需要在生成客户号的服务中使用企业的递增序号服务来响应客户号生成请求：

  注意企业资源服务提供的“IncreaseCounter”方法是需要填入一个序号类型名的，这和我们新增的“ClientNumber”配置的节点名一致。发布服务工程并重启企业资源和服务进程，测试一下：

  测试结果已经验证了生成客户编号服务可正常提供服务了。

定义服务应用

---

  按需求在应用架构中合适的位置开始进行模型定义。

设计服务应用ADML逻辑

---

  这里就不再把每个服务应用的ADML设计均演示一遍了，以创建个人客户基本信息服务为例。

  按业务需求将其他服务应用的ADML设计完成，最后发布服务工程进行测试，这些步骤同前文介绍，不再赘述。
  （更多关于可视化建模开发工具的介绍可以关注领驭框架（北京）软件有限公司的微信公众号和我自己的订阅号，或者到公司主页（www.eframesoft.com）查询。）