系统设计中业务规则与系统规则的应用

系统设计中业务规则与系统规则的应用
在面向商业应用开发系统的时候，常常会遇到业务规则的说法。这些商业规则也可称之谓策略，对业务流程起到了限制和约束的作用。在传统的应用系统开发和实施过程中。业务规则(Business Rules)是在需求分析阶段由用户提供，内嵌在程序代码中的。应用系统一旦开发完成业务规则便相对固定不易改动。然而业务规则充斥在应用系统的各个方面和角落，并且往往需要频繁的变更．应用系统的每一项策略、规则的变化都需要开发人员对源代码进行修改．限制了应用系统的灵活性和生命力。因此目前有许多商业或开源产品用来支持将业务规则从IT应用中分离出去，以提高应用系统的灵活性。例如IBM的business
process server等。这些新产品都使用了业务规则引擎技术。使用规则引擎可以在系统开发中更好的管理规则，避免代码随规则的改变而修改。

举个例子来了解什么是业务规则，大家都买过书，书店对于不同级别的会员实施不同的折扣，如果是金牌会员折扣为9折，白金会员折扣为8折。这两个不同折扣就是业务规则，它可能是易变的，可能在不同节假日调整这个折扣。

看完这个例子，我们再讨论业务规则对系统设计的影响。假如我们要开发一个会员管理系统，这个系统需要对不同级别会员在结算时实施不同的折扣。如果我们这些规则内嵌到代码中，可以相像，代码发布之后将会成为一场恶梦，一旦商家的折扣策略发生变化，我们都需要重新修改代码、重新编译和部署。没有人愿意为这种系统买单。最理想的作法是把这些业务规则都集中管理并且和应用系统分离，当应用系统需要使用的时候访问规则引擎，规则引擎负责查找匹配规则，并执行相应规则的操作，将操作的结果返回给应用系统。而业务规则引擎可以独立于应用系统，业务规则可以独立变化，从而使用系统可以从容应对商业变化。

我们开发的系统可能没有过多复杂的业务规则，没有必要使用重量级的规则引擎产品，但具备分析和管理业务规则的思想对于开发系统也是有益的。我们可以把业务规则集中在文档中记录，由某个组件专门处理这些业务规则，使得这些外部约束不会分散在整个系统中而难于维护。即使是做不到集中和自动管理，也要在尽量把规则的约束参数化，通过外部配置来支持最大的变更。比如在上面的会员系统中，如果商家确定只会有这两种会员，且不需要过于灵活，可以把不同的折扣写入到配置中，允许商家通过相应的接口来配置这两个折扣。

当我们开发的商业应用到一定程度时，我们还会遇到系统规则，系统规则是指当我们用计算机系统实现这些商业应用时，为了保证商业应用的正确和有效等，对计算机系统施加的限制，系统规则并不是来源于业务规则。例如上面的系统中，如果系统要支持会员在线订购，为了保证系统正常有效，必须限制并发访问量，比如如果并发访问会员达到5000时，需要限制会员的登入。然而多数时候业务规则和系统规则是难于分辨出来的。例如：如果用户输入密码失败超过5次后，即冻结用户帐户。这个规则很难说清楚是业务规则还是系统规则。那么如何来区分二者呢？

评价一个业务规则需要从三个方面来进行：

1 可执行性。即一条规则可以让人知道做什么或不做什么。例如不用身份证就不能修改帐户密码符合此要求，而用户身份必须合法则不符合此要求。

2 业务适用性。即一条规则适用于业务，而不是适合于业务的支撑系统或系统的运行平台。

3 业务描述性。即一条规则是可由业务语言描述的，而不是只能由系统语言或平台语言描述。

有了这三条再看上面的例子，就容易得出它是个系统用例，而非业务用例。其不符合需求2。业务规则在系统实现时表达为系统语言形式，但其只是表述形式发生变化，其仍然是业务规则。

按照业务规则相同的思想，系统规则也是可以考虑集中管理的，由“系统规则引擎”来实施相应的规则匹配和执行。我们可以在系统中实现自己的规则管理器，如果规则变化不大规则也可以实现自己的规则配置管理。

简单的规则管理有两种层次，一种是把规则和规则执行编码到应用中，但规则的条件边界通过配置可变化。更高层次是规则和规则执行以及边界条件都抽离到单独的组件来管理，个人能力有限，不能详细描述，这里只抛砖引玉这么多。