如何跟踪不断增长的业务规则目录？

Question

在我的上一个应用程序中，每个人都开始失去对商业规则日益复杂的控制，而商业规则每周都会添加--最重要的是应用程序所有者自己。最后，我们不得不向他们解释他们自己的应用程序的行为，因为他们忘记了几周前他们定义了什么。

在我当前的应用程序中，我看到类似的情况即将来临；在他们的日常业务中，应用程序所有者面临着单一客户端的问题，他们通常将这些客户端转换成业务规则，例如:如果当前客户端是xy，则使用不同的通知模板。

我们试着使用Lucid曲线图来创建某种图表或线框，以跟踪应用程序实际应该做什么。我将使用ID (即#01 )标记线框中的规则，然后将该ID引用到实际代码。但很难让所有人都参与进来，尤其是非技术人员(企业主)。

保存业务规则的有组织目录的格式是什么，作为编码器、项目经理和业务所有者的参考？

如果有人想否决这个问题，请解释原因。

Answer 1

需求需要被记录下来。您已经在尝试这样做了，但是需求通常被细分为几个类别：

• 业务需求-类似“博客帖子需要一个标题”之类的东西将被视为业务需求。
• 功能需求--这些更详细地说明了应用程序的行为。技术术语开始出现：“如果blog post标题字段为空，则显示以下验证消息：”标题是必需字段“
• 技术要求--充斥着技术术语，业务几乎无法理解：“使用FluentValidation中的FluentValidation(.)方法在BlogPostForm视图模型中标记PostTitle属性”不为空“

有许多专门组织需求的工具，但是对于这个站点来说，工具推荐是一个不相关的话题。

除了需求之外，名为行为驱动开发 (BDD)的开发方法(利用Gherkin语言)本质上允许您以自然语言格式编写用户接受测试，并使用与编程语言的绑定，这些测试成为实际的功能测试，可以与真实的用户界面和数据库进行交互。

BDD的一个优点是您的业务需求成为随着应用程序的发展而通过或失败的测试。为了保持测试通过，您需要更新业务规则。为了使应用程序继续执行新的或更改的业务规则，您需要在重写规则之后更新应用程序。它迫使您保持文档的最新，因为您的测试失败。

Answer 2

将规则的编写与软件更新的部署分开。

如果您有很多不同的业务规则，那么您可能需要考虑使用业务规则引擎，它有助于为产品所有者执行的规则管理提供UI，并使用API来执行和执行规则，这些规则由软件(以及编写规则的开发人员)完成。

如果您的规则正在快速增长和变化，那么整个团队很难对每个规则进行整个开发测试构建部署周期。规则引擎将有助于将规则的创建和“部署”与软件更新的部署分离开来。

例如，Java的一个开源规则引擎是Drools。

https://www.drools.org/

这比使用BDD框架或用BDD风格的语言记录规则要花费更大的前期成本，因为它涉及建立一个运行的系统来管理规则编写，但好处是规则更改可以比使用BDD更快地到达生产。它可能适合于软件中的规则数量，也可能不适合，但是如果规则的变化速度快于软件所能改变的速度，这是与您的团队讨论的一个选项。