use-case.md

使用模式及情景举例

适合于流水化处理，不需要即刻得到结果的情形。不适用于强交互，需要即刻反馈结果的应用，如画图。

Nature检测复杂条件，触发后续处理

• 情景：打印发票需满足条件，已经拣货+已经支付。
  • 方法：用状态数据来解决。并在Relation的配置中选择多个状态。
  • 类似情景：多人审核、多级审核
• 情景：打印发票需满足条件为订单上下文中有[发票=true,发票类型=纸质]。 方法：用状态数据来解决。并在Relation的配置中选择多个上下文。
• 情景：打印发票既要检查订单的上下文又要检查订单的状态。 方法：用状态数据来解决。并在Relation的配置中选择多个上下文和多个状态。

执行器检测复杂条件，适用于确定性条件

所谓的确定性是指，条件不会变， 如订单金额，会员生日等。

情景：对订单支付金额大于1000，且是生日的派发生日礼物。

• 方法1：生成订单数据时提交到 Nature 前进行处理，如满足则补充订单内容，然后提交给Nature。这种方法可以一个订单来完成，业务系统需要修改，不是可插拔的。
• 方法2：在正式订单之前增加一个“准订单”Meta，建立准订单与正式订单的Relation，并在这个Relation的Executor中处理这个需求。此方法的问题是需要改动调用端来生成准订单而不是正式订单，另一个问题是，Executor的实现不稳定，很容易受新需求的影响。
• 方式3：增加一个“生日订单”的Meta，建立订单与生日订单的Relation用于生成一个特殊的订单。物流成本可以由合单技术来解决。

Meta 不变，查询特定某类Instance

• 情景：论坛 方法：用参数化的方法来解决主题与子贴的问题，参数化可提供前模糊匹配查询。

延迟执行

• 情景：订单发货15天后自动签收 方法：在“配送单->签收单”关系中定义延迟15天的延迟就可以了。

办公流程审批

• 情景： 请假单，不同的部门不同的领导批，审批层级数设置。 方法：建立关系“请假单->请假审批状态:初审”，执行器依据请假单中的员工找到所在的领导，给领导发送个连接。领导查阅后将请假审批状态提交到 Nature。建立关系“请假审批状态:初审->请假审批状态:终审”，执行器做类似于第一步的操作。

流式计算

• 情景：top 统计

  方法：有下面的步骤

  • 建一个“统计时间”Meta，建立Relation：统计数据->统计时间，Executor生成带有"计划统计时间“参数的Instance，并且设计其系统上下文的延迟属性，Nature 会依据此上下文来设置下一个Executor的执行时间。
  • 建立一个“统计结果”Meta，建立Relation：统计时间->统计结果。该Relation的Executor会在指定的时间被触发，检索提交的统计数据，并求出top。

• 情景：分别输入语数英的成绩，输入完后求总分

  方法：新建关系“学科分数->分数登记”，其中分数登记为状态数据，用于记录总分，每个学科一个状态，全部学科都有分了一个状态。

• 情景：销量统计

  方法：不能再应用类似于成绩统计方法，性能会有很大的问题。需要引入定时批量策略。有下面的定义，这里仅列出分钟和小时统计方法，更长时间的统计可以此类推：

  定义关系	说明
  订单->分钟统计定时器	一分钟的订单都会触发同一个分钟统计定时器。但只会生成一个（建议时间参数化），并设置延时执行上下文，让下一个真正的统计Executor在当前分钟结束后执行。
  分钟统计定时器->商品销量分钟统计结果	Executor依据定时器的时钟值读取所有分钟内的订单，生成每个商品的销量统计。
  商品销量分钟统计结果->分钟统计定时器	处理方式类似于 订单->分钟统计定时器