对于经常变化，或多样性很高的业务规则，直接由程序员使用开发语言编写并不明智。如使用java，c#等语言直接表达企业的规定、制度或管理办法，甚至不定时修改的计算公式，这并非合理的做法。编程语言、数据表结构、分布式部署等因素综合之后，这些业务逻辑会变得不好维护。传统的IT专家会认为只要需求做得好，分析透彻，所有的系统需求都会被定义，可以使用一定的表结构和设计来降低或解决这些频繁的修改或多样性。但如果业务的变化范围很大，多样性是天马行空的，或当前根本没有需求，而是决策者在一定时期根据形势而作出的决策，那即使不考虑金钱成本，业务系统是否又能快速响应呢？

    引入规则解决方案，是一个大趋势，与传统相对，她对频繁变化和多样式的决策反应非常的快，是一个较合理的手段。引入之后，业务系统的生命周期，如软件需求采集，系统分析设计，编码，测试和维护都会发生深刻的变革。

    在并行开发的情况下，对于新开发的系统，业务规则是作为需求采集的一部分。业务规则的采集是通过不同的需求交付物（如领域模型和业务用例）来收集。从深层次来讲，业务规则重点强调的是业务基本理由（规则背后的业务策略和动机），并不是关注被基本理由所驱动而产生的业务动作。相应地，我们需要特定的过程，角色，技巧和交付物去处理业务规则。同时，这些收集“业务规则”或“中间交付物”的过程和技巧，依赖于公司一直使用的传统需求采集技术。如公司一直是使用用例来采集功能需求的，那么业务规则的采集就应该基于这些用例所表达的决策步骤的上下文信息。对于重构系统的情况，现存的系统和文档可以作为需求采集一个重要内容，也是业务规则的来源，这种情况下，规则发现的过程和技巧是同样适用的。   

    在非同步开发的情况下，我们需要清晰地把业务规则与过程、角色、技巧和交付物分开。与特定的业务程序的需求采集分开的。

    系统设计

    系统的分析与设计，要更加关注业务并依赖规则引擎去执行业务决策，除此之外，系统的基础架构应该要尽量少地被特定的规则解决方案所影响。程序的分析和设计时，会有更多的规则或决策方面的内容。我们需求做规则分析的工作，包括将重复的业务逻辑分解为若干简单的自动化的逻辑，检测规则之间的冗余、重复或冲突，记录业务规则的决策意图。还需要根据业务需求或程序设计的需求，将规则打包成一个规则集，该规则集由测试、部署和执行等一体化的组件组成。我们还要清晰地设计和列出业务规则管理系统(BRMS)的管理部件，包含规则库的结构，规则元数据，用规则改变流程的措施等等。最后我们要设计业务程序与规则管理系统的相互调用接口。

    编码

    基础架构的代码编写，不受规则解决方案的影响。但是决策逻辑将会被分离出来，通过一个业务规则管理系统(BRMS)进行编写，我们需要新的流程，技术，技巧，角色和工具去编写业务规则。这样的分离的结果是这两方面的程序可以减少耦合并相对独立地推进。当项目的基础架构完成之后，不用等到第一个业务规则代码类编写出来和测试，我们就可以参与到项目中。这种情况下，客户会怀疑"为什么还在需求采集中，就已经将研发团队放回公司了"，但我们在未写一个业务逻辑层代码之前，就已经完成所有的业务规则的编写，大部分规则也已经被测试。这样，规则编写问题和系统架构会相对独立。

    测试

    在传统的系统开发中，功能测试是在程序已经被开发出绝大部分时才会进行的。进一步讲，黑盒功能测试没有为程序业务逻辑方面的调试提供什么帮助，反之白盒测试需要我们分析和辨别复杂逻辑运行环境中的逻辑路径。而使用规则解决方案，我们可以用较少的架构代码，测试相对独立的功能。这就像通过代码执行功能的单元测试，可以辨别，跟踪，修改独立的逻辑路径。独立规则的测试能力是一个强大的验证和确认的工具。

    维护

    在传统的系统开发中，维护请求都走一条相似的实现路径，不分业务规则还是基础架构代码，都基本这样：管理员签发维护请求，该请求会下发到IT人员的手，去实现、测试和部署。在规则解决方案的帮助下，业务规则或决策逻辑被独立地部署和维护，我们有不同的业务流程来识别业务规则，并使用轻量级的规则部署机制。业务规则维护是整个业务管理活动中的一环。规则管理受同步或异步开发模式的业务规则解决方案所深深影响。