CHBN-URC

Appearance

事件驱动 ​

规则引擎内部是基于事件驱动的模型实现的，事件/事实/领域事件/聚合根模型或标准业务对象，在规则中心的语境下都指向了同一个语义：驱动引擎工作的事实的结构化信息。这是我们重中之重的关注点，因为所有的业务规则都是基于它进行简单或者复杂的决策。

领域服务 ​

  • 领域服务的触发点，具有全局唯一性，是RESful API的端点信息/统一资源标识符
  • 通过触发点，可以关联知道这个接口处理什么样的事实数据
  • 通过触发点，可以关联知道这个接口处理什么样的逻辑规则（在规则文件中定义）
  • 通过触发点，可以知道要不要去取数补全，适用那个取数插件，去补全事实数据
  • 通过触发点，隐藏了规则信息和决策需要的完整事实的结构信息，因为内部可以间接关联出来。
http
POST /api/event-driven HTTP/1.1

{
"rule": "执行的规则信息",    
"eventType": "执行的事件信息类型，即事实结构",    
"eventData": {"完整的事实数据"}
}

通过定义富有业务语义的触发点(trigger point)以及配置规则单元(rule unit)单元（关联取数插件），调用方仅需要传递如下信息：

http
POST /api/event-driven/{trigger-point} HTTP/1.1

{
  "部分事实数据"  
}

通过对比可以看到，引入领域服务的应用接口的配置，可以大大简化调用方的请求报文格式，而且在URI上就可以清晰看到业务上的语义。

事实数据 ​

  • 通过自动关联的取数插件，调用事件源/业务中心的GraphQL API，获取完整的事实数据。
  • 如果使用到多种不同的事实数据（比如客户中心的客户信息，产商品中心的产品信息），那么可能要进行多线程并发请求。
  • 目前使用AsyncTool作为线程并行框架，加速从多数据源获取数据的过程。

规则数据 ​

  • 目前适用Drools的新语法 rule unit 风格编写，可能需要将数据库或缓存中的规则内容(content)，按照指定的格式(format)，保存到指定的文件中(name）。
  • 后续研究一下官方的文档，看Drools是否提供直接执行规则文本内容的接口，这样可以减少读写文件的时间。