业务规则方法的基本原则
2006-10-09 10:50
183 查看
《业务规则方法原理》以防火门为例子讲解了业务规则方法的基本原则。
规则为“在任何时候此门都必须关闭”。如果严格遵从这条规则,那么门就不是门了,就成为了墙了。所以对规则做一点分析,更完整准确的描述应该是“可以通过此门出入,但必须随手关门”。
现在罗列如下:
规则应该明确的写下来:如果规则足够重要,就必须写下来
规则应该用简明的语言描述:规则必须容易被人理解,就像上述防火门的规则描述一样,第一个描述不易被人明白。
规则应该独立于规程和工作流程而单独存在:对于防火门可以写一个规程“走近门、用手握住门把、顺时针转门把.......”,不过这样没有什么价值。所以规则应该独立于规程而单独存在。
规则应该建立在事实基础上,事实应该建立在由术语表达的概念基础上
规则应该以所期望的方式指导或影响行为:防火门规则会督促员工不忘记关门
规则应该由可识别的重要业务要素驱动:规则是有用途的,不能模糊。防止门可以防止火灾发生。
规则应该能够供被授权的部门使用:保证规则能够被遵守的最好方法就是让规则在需要它进行提示的时候正好出现在人的面前。
规则应该只有一个来源:防火门规则是大楼日常消防措施体协的一部分,不管把这个规则张贴成千份,规则来源也只有一个。
规则应该直接由具备相关知识的人描述:消防措施体系必须由具有该领域经验的专家制定。
规则应该收到管理:规则必须经过精心的评审、批准、集成和落实。
规则为“在任何时候此门都必须关闭”。如果严格遵从这条规则,那么门就不是门了,就成为了墙了。所以对规则做一点分析,更完整准确的描述应该是“可以通过此门出入,但必须随手关门”。
现在罗列如下:
规则应该明确的写下来:如果规则足够重要,就必须写下来
规则应该用简明的语言描述:规则必须容易被人理解,就像上述防火门的规则描述一样,第一个描述不易被人明白。
规则应该独立于规程和工作流程而单独存在:对于防火门可以写一个规程“走近门、用手握住门把、顺时针转门把.......”,不过这样没有什么价值。所以规则应该独立于规程而单独存在。
规则应该建立在事实基础上,事实应该建立在由术语表达的概念基础上
规则应该以所期望的方式指导或影响行为:防火门规则会督促员工不忘记关门
规则应该由可识别的重要业务要素驱动:规则是有用途的,不能模糊。防止门可以防止火灾发生。
规则应该能够供被授权的部门使用:保证规则能够被遵守的最好方法就是让规则在需要它进行提示的时候正好出现在人的面前。
规则应该只有一个来源:防火门规则是大楼日常消防措施体协的一部分,不管把这个规则张贴成千份,规则来源也只有一个。
规则应该直接由具备相关知识的人描述:消防措施体系必须由具有该领域经验的专家制定。
规则应该收到管理:规则必须经过精心的评审、批准、集成和落实。
相关文章推荐
- 测试SQL Server的业务规则链接方法
- 测试SQL Server业务规则链接方法
- 面向服务的方法在业务规则开发中的运用
- 业务规则被划分在SQL 2005的存储过程与.NET 2005的CRL类方法中,统一调用的解决办法
- 测试SQL Server业务规则链接方法
- java中:包、类、字段、方法命名规则
- 实现业务逻辑的几种不同方法,及其优缺点 事务脚本、表模块、活动记录、领域模型
- 面向服务体系架构的业务规划和建模方法系列之二--基础概念辨析 推荐
- Java方法重写规则
- 我的建模可以复制-8 (体系化的描述业务场景、业务规则)
- 规则引擎系列:业务规则分类
- 面向服务体系架构的业务规划和建模方法系列之四--实践案例介绍“汽车贷款 推荐
- 伪静态在iis下的规则和设置方法
- 【SpringMVC】一个Action中,写多个业务控制方法(十一)
- K2.Net 2003中的5种业务规则(Rules)[转]
- mcafee杀毒软件编写规则时通配符使用方法
- springmvc中,结果的转发可以共享request域对象,会将参数从第一个业务控制方法传入第二个业务控制方法,重定向则不行
- struts2:多业务方法的处理(动态调用,DMI)
- nginx带问号(?)带参数的rewrite规则的书写方法
- JNI/NDK开发指南(二)——JVM查找java native方法的规则