业务规则和规则引擎

规则引擎

Version 1.0.0

作者：Johnny Leon 发布日期：2016-08-08

目录

1业务规则 (3)

1.1什么是业务规则 (3)

1.2业务规则的例子 (3)

1.3业务规则的分类 (3)

1.4业务规则的特性 (4)

1.5业务规则的要素 (4)

2规则引擎 (5)

2.1规则引擎是什么 (5)

2.2规则引擎的组成 (6)

2.3规则引擎的推理 (6)

2.4规则引擎的应用 (7)

2.5业务规则的提取 (9)

2.6业务规则的管理 (10)

3典型案例 (10)

案例1：信用卡申请 (11)

案例2：企业薪资计算 (13)

案例3：保险公司核保理赔 (13)

案例4：快递产品报价 (14)

案例5：电商促销 (14)

1业务规则

1.1什么是业务规则

与业务相关的操作规范、管理章程、规章制度、行业标准等，都可以称为业务规则（Business Rules ，简称BR）。业务规则描述了业务过程中重要的且值得记录的对象、关系和活动。其中包括业务操作中的流程、规范与策略。业务规则保证了业务能满足其目标和义务。

业务规则实质上也可以理解为一组条件和在此条件下的操作，是一组准确凝练的语句，用于描述、约束及控制企业的结构、运作和战略，是应用程序中的一段业务逻辑。该业务逻辑通常由业务人员、企业的管理人员和程序开发人员共同开发和修改。

业务规则的理论基础是：设臵一个条件集合，当满足这个条件集合时候，触发一个或者多个动作。

以规则形式捕捉策略语句能提供极大的灵活性和良好的适应性，是企业保持竞争优势的决定性因素。在市场驱动的情况下，系统架构和模型必须对客户、竞争对手、合作伙伴和整个市场情况的各种变更及时响应，同时将这些变更产生的需求作为业务规则体现到系统中去。

业务规则技术的基本思想是将系统处理的业务逻辑从程序代码中抽取出来，将其转变为简单的业务规则，以结构化的业务规则数据来表示业务行为，采用类自然语言来描述，并集中存储在规则库中。业务规则由业务人员创建、实时更新和调试，业务规则之问的复杂逻辑关系由规则引擎处理。业务规则技术改变了传统的、以过程形式处理业务逻辑的方式。1.2业务规则的例子

生活中的一些业务规则可能是：

当顾客进入店内，最近的员工须向顾客打招呼说：“欢迎来到×××”。

当客户兑换超过200元的奖券时，柜员须要求查看客户的身份证并复印。

当兑换的奖券金额小于25元时，无需客户签字。

早上第一个进办公室的人需要把饮水机加热按钮打开。

找一些数据相关的业务规则，一些例子如下：

?只有当客户产生第一个订单时才创建该客户的记录。

?若一名学生没有选任何一门课程，把他的状态字段设为空。

?若销售员在一个月中卖出10套沙发，奖励500元。

?一个收件人必须至少有1个电话号码和1个收货地址。

?若一个订单的除税总额超过1000元则能有5%的折扣。

?若一个订单的除税总额超过500元则免运费。

?员工购买本公司商品能有5%的折扣。

?若仓库中某货品的存量低于上月卖出的总量时，则需要进货。

1.3业务规则的分类

业务规则主要分为五类，第六类规则是术语，即专门定义的、对业务很重要的词、短语或缩略词汇，通常在术语表中定义术语。

1. 事实（fact）：通常是对业务的真实陈述，常常与重要的业务术语关联，事实也称为不变量——关于数据实体及其属性的不可改变的真实情况。

2. 约束（constraint）：约束限制了系统或它的用户可以执行哪些操作；例如：图书馆的借阅者最多可以同时借10本书。

3. 动作触发规则(action enabler)：在特定条件下触发某个动作的规则被称为动作触发规则；例如：如果某瓶化学药品到了失效日期，则通知其当前持有人。

4. 推论（inference）：推论是根据某个条件的真实性得出某些新事实的规则，通常用“如果/则”的句式来表达；例如：如果到期30天后还没有偿还应付款，则该帐户是在拖欠债务。

5. 计算（computation）：使用特定的数学公式或算法进行的计算业务规则；例如：订单的数量为6件～10件，则单价降低10％，数量为11件～20件，单价降低20％。

1.4业务规则的特性

1、原子性。业务规则不可再分，每条规则只定义一种判断和操作，复杂的业务逻辑由多条规则协同处理。

2、独立性。业务规则彼此之问独立，复杂的逻辑关系由规则引擎来处理。业务规则存储在规则库中，独立于数据和程序。

3、简单性。业务规则用简单直接的类自然语言来描述，很容易被业务人员和技术人员所理解。

4、动态性。业务人员可以实时地修改业务规则，快捷地更新系统，低成本地维护系统。

5、逻辑性。业务规则至少包含条件和执行两个部分，条件是对业务数据作用的判定，执行是对业务数据的处理。在基于业务规则的软件系统中，业务规则存储在规则库中，业务人员可以进行查询、添加、更新、统计，可以不断积累经验，实现对业务行为的知识管理，这使得业务规则与单位的数据信息一样成为单位的重要资产。

1.5业务规则的要素

业务规则最基本的组成成份是用于表示它的语言，业务术语是人们用于定义事物的工具，例如术语表。一个组织的本质和运行结构可以用相关的术语来描述，如“客户借一笔1年期流贷”，类似“企业信用评级不可以低于A”这样的规则则能够限定和控制企业的某些行为。此外，利用业务规则可以从一种知识推导出另一种知识。

业务规则的属性包括名称、状态（被提议的、有效的、被核准的、终止的）、有效日期和终止日期、业务规则描述、表达式、触发事件等。其主要形式有决策表、决策树、规则语言和脚本。

?决策表:以表格的形式表示业务规则，每一行表示一条规则，列表示条件或动作，当所有

条件满足时，执行动作。

?决策树：将一组业务规则以树型结构来表示，每一个分支表示一条决策路径，叶子节点

表示结果或动作。

?规则语言：使用类似自然语言的句法描述规则。目前有很多种规则语言，每种语言适合

解决其特定领域的问题，可以提供较好的性能，但比图形化的表示难于维护。

?脚本（模板）：用于描述过程性的业务逻辑，是决策表、决策树、规则语言的基础。如：

IF...THEN...ELSE...。

2规则引擎

在很对行业的系统应用里，业务规则往往非常复杂，并且处于不断的更新变化之中，而现有很多系统的做法，是将业务规则绑定在程序代码里；当业务规则变更时，对应的代码也必须得跟着修改，每次即使很小的变更都需要经历开发、测试、验证、上线等过程，变更成本比较大；长时间的规则变更，系统变得越来越难以维护；如此以往，系统变得僵化、新需求插入也比较困难，上线周期也较长；另一方面，开发人员熟悉业务的程度远远比不上业务人员，却需要承担将业务规则准确无误实现的重任；

使用传统的应用系统开发和实施方法，业务规则相对固定不易改动。系统的每一项策略、规则的变化都需要开发人员对源代码进行修改，业务规则动态的特点使传统的解决方案越来越难以满足电子商务业务系统的实际需求，限制了系统的灵活性和生命力。

所以能否让我们的业务系统更灵活一点呢，将业务规则从技术实现中提取出来，实现技术和业务的分离，开发人员处理技术，业务人员定义业务规则，各自做自己擅长的事，这个方法就是所谓的规则引擎；

以电子商务为例，电商促销是一种典型的业务规则需要频繁改动的应用；各电商平台为了吸引用户，不断推出新的服务和优惠活动，以满足不同层次、不同时期用户的需求和业务需要；为快速响应竞争，这些业务策略的改变需要在很短的时间内完成，比如几个小时、当天或几天，这就意味着这些改变要由运营商自己的业务人员而不是软件的开发人员来实施；此外，电子商务业务处理的数据量巨大，每小时要处理的数据可能高达几千万条。

引入规则引擎之后把业务规则从具体的程序代码中剥离出来。业务规则不再以程序代码的形式驻留在系统中，取而代之的是处理规则的规则引擎，业务规则存储在规则库中，完全独立于程序。业务人员可以像管理数据一样对业务规则进行管理，比如查询、添加、更新、统计、提交业务规则等。业务规则被加载到规则引擎中供应用系统调用。

2.1规则引擎是什么

BRMS (Business Rule Management System)业务规则管理系统，俗称规则引擎，是由推理引擎发展而来的一种专家系统；专家系统是人工智能的一个分支，它模仿人类的推理方式，使用试探性的方法进行推理，并使用人类能理解的术语解释和证明它的推理结论。专家系统有很多分类：神经网络、基于案例推理和基于规则系统等；

规则引擎的主要思想是将应用程序中随着时间、空间动态易变的业务决策部分分离出来，并使用预定义的语义模块编写业务决策，由用户或开发者在需要时进行配臵、管理。

规则引擎实现了将业务决策从应用程序代码中分离出来，接受数据输入，解释业务规则，并根据业务规则做出业务决策。

它可以为企业带来许多好处：

?分离商业决策者的商业决策逻辑和应用开发者的技术决策

?能有效的提高实现复杂逻辑的代码的可维护性

?在开发期间或部署后修复代码缺陷

?应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内

?符合组织对敏捷或迭代开发过程的使用

?规则能作为知识被保留下来，不会随着关键人员的流失而流失

在规则引擎为企业带来的诸多好处中，最重要的三点，就是带来业务系统的敏捷性、企

业业务知识的沉淀以及为决策分析提供支持。

要真正达到以上几点，就需要规则引擎产品能够：

?提供友好的规则设臵界面，让业务人员自行设臵规则

?提供完善的管理功能，使用软件工程的思想管理规则的开发过程

?提供良好的嵌入式架构，规则不仅能在BRMS中编辑，也能在业务系统中编辑，从而真

正做到规则管理无处不在。

2.2规则引擎的组成

规则引擎的任务是把当前提交给引擎的数据对象与加载在引擎中的业务规则进行测试和比对，激活那些符合当前数据状态下的业务规则，根据业务规则中声明的执行逻辑，触发应用程序中对应的操作。

它主要包括以下三部分：

RuleBase（规则集）、WorkingMemory（工作存储器）和InferenceEngine（推理引擎）；

推理引擎包括三部分：

PatternMatcher（匹配器）、Agenda(议程)和ExecutionEngine（执行引擎）；

它们的结构如下所示：

1）规则集容器，用于存放从规则库中提取的对应当前问题的一组规则；这些规则将按照某种数据结构组织，当工作区中的数据发生改变后，引擎需要迅速根据工作区中的对象现状，调整规则执行队列中的规则。

2）工作存储器，即规则引擎的综合数据库，也称为事实库；用于存放规则系统运行时所需要的各种信息；其中的信息用来与规则集容器中的规则进行匹配。

3）匹配器，是规则引擎工作的上下文环境，用来关联规则集容器和工作存储器；将规则集容器中的所有规则与工作存储器中的事实进行模式匹配，匹配成功的规则将被激活，并与前面推理得到的所有激活规则构成规则冲突集。

4）议程，议程中存放的是根据需要进行过排序的规则冲突集。对匹配生成的规则冲突集进行排序的过程称为冲突消解；然后议程中首条规则的结论或动作部分将会执行，这可能会产生新的事实，从而改变工作存储器的内容；整个过程将一直循环下去，最终得到执行结果。

2.3规则引擎的推理

推理引擎通过决定哪些规则满足事实或目标，并授予规则优先级，满足事实或目标的规则被加入议程。

存在两者推理方式：演绎法（Forward-Chaining正向链）和归纳法（Backward-Chaining 反向链）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是从假设出发，不断地寻找符合假设的事实。

规则引擎的推理步骤如下：

a将初始数据（fact）输入至工作内存(WorkingMemory)。

b使用PatternMatcher将规则库(Rulesrepository)中的规则（rule）和数据（fact）比较。

c如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。

d解决冲突，将激活的规则按顺序放入Agenda。

e执行Agenda中的规则。重复步骤b至e，直到执行完毕Agenda中的所有规则。

当引擎执行时，会根据规则执行队列中的优先顺序逐条执行规则执行实例。由于规则的执行部分可能会改变工作存储器中的数据对象，从而会使队列中的某些规则执行实例因为条件改变而失效，必须从队列中撤销，也可能会激活原来不满足条件的规则，生成新的规则执行实例进入队列，于是就产生了一种“动态”的规则执行链，形成规则的推理机制，这种规则的“链式”反应完全是由工作存储器中的数据驱动的。

2.4规则引擎的应用

只要是“规则敏感”的地方都是BRMS的用武之地。例如：在计费系统中，BRMS已被国内外的运营商使用在计费的话单预处理，批价，帐务等不同阶段。在中国， BRMS首先应用在优惠和营销方面。

大客户管理和渠道管理也是BRMS的应用热点，因为这些应用领域，由于不同客户、不同区域所使用的业务规则都不相同，如果采用传统的“按需编写程序”的方式，往往会使系统开发和以后的维护成本急剧上升。但是使用BRMS，开发商就有可能开发出一个稳定的平

台，而规则可以在不改动程序的前提下按需定制。

在OSS方面，规则引擎主要使用在服务管理，网络管理方面等。例如HP著名的OpenView Temip就利用ILOG Rules实现了对告警的相关性分析和过滤。一些国内的电信设备供应商和网络管理开发商也开发了不少基于规则引擎的网管系统；

一个例子：

抽象：

那么，完成规则引擎的应用，需要哪些东西呢？

1、可视化规则定义；负责业务规则的定义和实现，需要方便业务人员进行操作；业务人员

通过鼠标拖拽等方式，使用规则组件完成业务规则的定义，规则定义要支持智能检查，比如条件永远为真或假、自我矛盾、冗余、未完全覆盖等等；

2、业务规则管理；负责业务规则的查询、添加、删除、修改以及规则冲突检测，以及业务

规则的生命周期管理；

3、业务规则验证；负责对用户的规则定义和实现进行正确性和有效性验证，是业务规则投

入使用前正确运行的验证环节，是一个必要环节；

4、业务规则引擎；业务规则的匹配、解析和执行，执行按照优先级顺序进行；

5、规则执行监控；负责对正在执行的业务规则进行查看、暂停、中止、取消和设臵优先级；

6、外部数据接口：负责在业务规则匹配和执行中从数据源存取数据的接口；

7、规则定义组件；以组件的方式方便业务人员进行规则的定义，组件负责定义业务实现中

的公共部分，用户通过组件的组装可以定义规则；

2.5业务规则的提取

由于规则引擎应用的实质可看成是一些特殊的脚本语言解释器，因此它们在理论上可以有任意的灵活性，可以对应用进行任意的扩展。但是，如果整个系统都由规则来实现，反而在性能和可维护性上大大落后于普通的系统。因此，在系统中使用基于规则的方法时，首先要限定规则的适用范围，即哪些是不适合用规则来实现的。

基于业务规则的方法专注于真正和业务相关的部分。核心是将应用中的业务规则从程序中抽取出来，以方便业务人员的对现有业务的理解、管理、修改或增加新的规则。业务规则必须包含且只包含业务人员关心的业务信息。

（1）业务规则是关于业务的，而不是关于常识的。

例如：手机浏览网站0.03元/KB是业务规则，而一次上网费用等于总流量乘以单价则是常识；如果是20元/100MB套餐用户，则每月流量在100MB之内的总共收费20元，之外的按照0.03元/KB计算，这是业务规则，而一次上网的费用等于各服务类型费用之和则是常识。（2）业务规则是描述性的而不是过程性的。

由于是给非技术人员用，业务规则不应使用条件分支、循环等技术性很强的结构。每条业务规则都是描述性的，有唯一的名字，且可以分组。当规则之间或规则组之间有相关时，这种相关性由独立的规则来描述。例如：某套餐用户每月手机上网有2M的夜间免费流量，还有5M的任意时间免费流量。这两条业务规则之间有这样的关系：如果在夜间的2M免费流量还没用完，则先用这个；否则考虑5M免费流量。此关系可以用定义前一免费规则的优先级高于后者来描述。

（3）业务规则是基于自然语言且面向所应用的领域的。

由于业务规则是非技术人员来管理的，因此业务规则不能是任何一种抽象的程序设计语言，而是基于自然语言的易理解易操作的一种语言架构，便于用户使用。

在一个应用系统中，常识部分一般变化较少。变化频繁且需业务人员自己快速处理的一般都是业务相关的部分。通过把业务相关部分从程序中分离出来形成业务规则，由于使业务规则的数目减少，并且业务规则又都是描述性的，因此，业务人员能方便地定义、修改和管理这些业务规则。此外，业务规则数目的减少还降低了解释执行它们的开销，使得使用规则方法带来的性能上的损失减少。

因此，基于业务规则方法的一个关键就是抽象出该应用系统领域中的所有常识部分，在应用程序中实现，并保证绝大部分的业务都可以在这些常识的基础上以业务规则来描述。

2.6业务规则的管理

业务规则管理主要是建立规则生命周期的管理流程，其他还有版本管理、权限管理、规则运行监控等。

3典型案例

案例1：信用卡申请

案例2：企业薪资计算

客户面临的问题:

某大型快递公司员工达二十余万，公司在薪资计算方面面临岗位类别多，不同部门、不同岗位的薪资计算方式不同，一线员工采用基本工资+派件计件制/收件计件制/派件计重制/收件计重制/大客户营销提成制等混合计薪方式，二、三线员工采用基本工资+绩效工资的计薪方式，且员工绩效工资随着公司绩效指标的变化而变化。薪资计算量大、计算规则复杂多变，原有的薪资计算系统不能满足薪资计算的要求。

解决办法:

通过在薪资计算系统中嵌入规则引擎，将薪资计算规则从应用程序代码中剥离，并通过规则配臵器对不同部门、不同岗位的薪资计算规则进行灵活快速地配臵，快速准确地完成海量数据的计算。

案例3：保险公司核保理赔

保险公司经营活动由一系列相互联系、彼此制约的环节组成，包括营销、承保、核保、理赔、合同维持、投资、计划与统计等。面对国民经济保持持续发展形势、积极拉动内需的消费政策及开放的市场竞争形势，我国保险业将继续呈现快速增长态势，但是同时也面临了很多的问题，而核保和理赔更是这些问题中的重点。

1、定价核保规则日益复杂，频繁变动

2、渠道商和监管部门的压力

3、信息系统不稳定，差错率居高不下，并且新的系统测试周期长，联测效率更是低下

4、面对市场竞争需求变更响应速度慢

5、人员流失严重（IT、运营服务等）

6、理赔速度慢，客户体验差

7、理赔欺诈风险带来的损失巨大

以上问题都严重影响了保险公司的服务水平提升，从而导致了客户流失，面对激烈的市

场竞争，这大大的制约了保险公司的更好发展。

基于规则引擎的自动核保和理赔：

通过提取保险公司的核保业务逻辑，把自动核保条件从程序代码中独立出来，保存为业务规则，核保系统通过调用规则引擎运行这些业务规则规则，实现自动核保功能。这样当业务规则发生变化的时候可以直接修改规则而不需要改动核保系统，这种方式为核保系统提供了良好的灵活性和扩展性。

保险理赔是一个广泛的用于车险理赔，人身伤残理赔，一种合理赔付等。

基于规则引擎实现的自动化理赔系统主要有以下几个方面：

1、人员清单导入

2、案件信息核对

3、案件理算

4、问题件处理

5、数据输出

案例4：快递产品报价

从快递行业现状看，受益于网购电商崛起快递业高景气增长，2015年快递业务量完成206亿件，同增48%，最高日处理量超过1.6亿件;快递业务收入完成2760亿元，同增35%。预计2016年业务量完成275亿件，同增34%;快递业务收入3530亿元，同增28%。

在整个行业高速发展的同时，作为行业中主角的快递企业在伴随着行业高速发展过程中也面对很多问题与挑战：如人员的快速扩充带来管理问题、客户更分散，服务产品门类更丰富，产品定价更灵活等。

现在的快递企业早已走过初期，单一产品服务所有客户的情况。现在的客户数量更多，群体更分散，个性化的需求更多。如何结合行业的发展，根据客户的需要制定出灵活、智能的产品定价系统成为了所有快递企业的必须认真思考的问题。

传统的快递企业定价系统采用原有的架构模式会存在如下问题：

1、开发周期无法得到保障；

2、业务总是在调整、变化，完全要求业务定型再构建系统不现实；

3、系统无法灵活的调整、变更；

4、系统无法满足区域和单独客户的定价和调整；

5、后期调整和维护更是需要IT部门一直支持。

采用规则引擎后，系统架构变的更加灵活，很多之前的问题都迎刃而解：

1、系统建设更迅速，并且有保障；

2、一改过去需求、设计、开发的传统模式，可以做到边调研边开发；

3、系统变的更灵活，完全可以根据地域、客户、业务的发展需要进行随时随地的调整；

4、基本区域和客户基本的调整，在后期业务人员自行调整就可，不过多的依赖IT人员。案例5：电商促销

在电子商务网站中存在着纷繁复杂的促销规则，这些促销规则可以是作用在产品上、购物车内若干产品或整个购物车，也可以是减免运费，额外赠送礼品、积分等。而且获得这些促销规则存在获取资格，比如某个会员级别、甚至是指定的用户等，那么如何在电子商务系统中通过一种统一的设计来实现各种各样的促销规则，并提供友好的扩展性方便以后挖掘的

更多的未知促销手段呢？

常见促销规则和例子

首先，让我们整理一下常见的促销规则和对应的例子。

整张订单消费满 x 节省百分比或数值 y

适合全站促销。

从指定的目录或者产品集合里面选购满 x 减百分比或数值

比如图书分类，满100减10，满200减25等

购买某个或指定范围的产品节省百分比或数值

符合某个条件赠送某个产品

符合某个条件赠送指定产品集合里面某个产品（任选一）

比如满98元任选一赠品。

买 x 则 y 免费（同上）

买 x 后，若买y 则节省y% 或某数值

这种和前面的不同，更加复杂，类似产品包优惠。

某个产品特价（指定价格）

减、免运费（无条件）

减、免运费（有条件）

比如订单满多少金额，或某个会员级别。

满足某个条件则最便宜的免费

在指定的产品范围内，超过3件产品，则最便宜的免费（即最高折扣为33% off）

额外的积分赠送

免费的礼品包装

满 x 送 y 优惠券

使用优惠券（Coupon）获得指定的优惠

.... 更多的或由上面的类型衍生出的促销类型

促销规则规律和设计分析

这些促销类型让人眼花缭乱，接下来我们要进一步分析，整理出隐藏在这些类型后面的规律。在这之前，要定义一个说明：促销规则是在购物车和结帐页面才会生效的。

在结帐页面比购物车多出的是对运费的处理（比如某些省份才免运费），其它的和在购物车内一致。只有在顾客将某个产品加入购物车后，基于购物车内的产品进行计算分析才会得出折扣后的价格、赠送或其它信息。

而在产品列表页面或详细页面，某些促销规则可以显示完整（如特价），某些则只能显示适用的促销活动标题了。

基于这个原则，将上述的促销规则分成下面的几部分，即每种促销类型均可以通过这些部分来表示和维护：

基本信息

包括标题、说明、图片等。

规则有效时间

起始时间和结束时间

规则组编号和优先级

适用于除生效条件和规则优惠不同外，其它参数均相同的促销活动。

关于分组和优先级的作用下面会详细阐述。

规则适用产品范围

分为单个产品、多个产品、产品目录、产品种类（含多个目录）和全部产品

规则生效条件

最小数量（含）或金额（含）

规则享受资格

全体会员、最低会员级别（含）、会员组（一般是临时组）、指定会员。

规则优惠

节省x%-->百分比值

节省x-->金额

赠送优惠券-->选择1～N优惠券类型

减运费-->金额

免运费

额外积分（百分比）-->积分百分比值

额外积分（数量）-->积分数值

赠品-->选择指定产品-->赠品数量

赠品-->选择赠品组-->可选赠品数量

指定产品-->折扣-->百分比

指定产品-->折扣-->节省金额

分组和优先级

在实际应用中，往往存在多个促销规则是类似的，比如：

图书满100减20元

图书满200减50元

图书满300减100元

这三个促销规则除了生效条件和对应的规则优惠不同外，其它的都是相同的，在促销引擎计算时，实际上只会计算一个最符合的促销规则，而不会累加。比如当前购买的图书是310元，那么适用促销规则3；240元，适用方式2，110元适用方式1等。

针对这类业务，我们可以通过增加一个分组编号和优先级来进行处理。对于这三个促销规则，我们在维护时，可以设臵分组均为1（简单的数字，默认是0）。而优先级从上到下，依次增加，数值越大优先级越高。这样促销引擎在计算时，就会按优先级来匹配，一旦匹配成功，同一组的其它规则就不再处理。

系统实现

从实现形式来分实际可也可以包括三块，其一影响商品类如：商品促销活动、商品优惠活动、买就送、商品折扣活动、买M送M等。其二影响订单类的营销方案如：满立减、优惠卷活动、满就赠、买M送N等。其三是影响物流类的营销方案如：满包邮，免运费等。

系统重点是营销活动的算法工式，在系统中每一种营销类别我们都必须定义好一种程序解决方案，也就是算法工式，不同的营销方式，程序处理的形式不一样，效果展现的形式也不一样。如影响商品的价格类的活动，在控制过程中主要是通过程序算法改变商品的价格；影响物流费用的营销类的营销活动，在控制过程中主要是通过程序算法改变物流费用；影响订单类的活动主要是通过程序算法为用户提供增值享受。在后台的营销活动定制中，当我们定制好营销活动后，即选择了程序算法。在前台的控制中就会自动响应该算法。

营销系统最难控制的是活动的重叠，如有一种商品参加了促销活动、也参加了买M送N、还参加了免邮活动等，最后的订单经程序核算后，客户最终付出的费用可能会超出平台商控制的范围。为了避免这种规则的重叠使用，必须在各级系统中可以自行设臵规则，尽可能的避名这种现象发生。

针对上面出现的问题，首先进行营销方案的分类，即影响商品的价格类、影响订单类、影响物流类三种，这三种模式上客户在平台中的消费可以叠加使用营销活动中的条件；而对于同一分类别中的营销活动，则需要通过营销活动的规则定制来避开优惠政策的重垒，如A 与B优惠条件同时出现时优先选择A等等。