业务规则应该在哪里执行？ [关闭]答案

【问题标题】：Where should the business rules be implemented? [closed]业务规则应该在哪里执行？ [关闭]
【发布时间】：2010-12-14 23:11:14
【问题描述】：

1) 它们是否应该在一个模块中通过它们的任何方法集实现？ 2) 是否应该在每个方法都测试特定业务规则的特殊类中实现它们？

另外...你能推荐我关于这个问题的任何好的参考书目吗？

更新：

“业务规则是企业、公司或公司的规则。它是定义或约束业务某些方面的规则，并且始终解析为真或假”Wikipedia definition.

【问题讨论】：

标签： design-patterns business-logic architecture

【解决方案1】：

首先，您必须对什么是“业务规则”有一个清晰的定义。有一群候选人：

有关您的产品的信息。
关于销售的规则取决于时间、地点、客户、产品、月相（也就是当月的截止日期）、季节等。
用户角色（例如，普通客户与首选客户等）
有关应付账款和应收账款的规则
GAAP 规则

你到底是什么意思？这是一个模糊的问题，如果你允许它可能会很大。

对于它们在代码中的位置，您有很多选择：

数据驱动，存储在数据库中
Rete 规则引擎中的表达式。
如果您正在编写 OO，则为中间层类。
如果您正在进行声明式编程，请使用属性或配置文件。
用 JavaScript 等表达的可执行规则。
在您的 ERP、MRP、A/P 和 A/R 系统中。
由您的应用组合在一起的 Web 服务提供支持。

你看到你要解决的问题了吗？您的问题意味着您有一个明确定义的问题，并期望得到一个简单、简洁的答案。事实上，这是一个广泛的话题。

【讨论】：

实际上，您向我展示了了解不同可能性的重要一步……这部分是我所期待的！
我现在正在使用维基百科上的定义......也许你可以相应地更新你的答案。
“业务规则是企业、公司或公司的规则”——只不过是重言式。在 Wikipedia 上查看这意味着什么。

【解决方案2】：

这是一个相当笼统的问题，很难回答——但我想说看看Behaviour Driven Development，作为将业务规则置于开发核心的一种方式。

【讨论】：

【解决方案3】：

我建议您研究 MVC 范式 - 模型视图控制器。视图中应该没有业务逻辑，应该都在模型中。

【讨论】：

偏离重点的答案。我不是在谈论视图层。我只是询问任何必须验证业务规则的业务组件......
我不确定它是否“没有重点”——该范式描述了一种设计，其中任何“业务组件”都是独立的模型，因此很容易测试。
在我看来过于简单化了。不是玩具的系统很少能在少数几个对象中如此巧妙地满足所有逻辑。
@duffymo：我倾向于不同意 - 但是，如果您使用的框架不容易允许 MVC 范式，那么实际上，您将不愿意将 MVC 用于小型玩具项目。一个典型的例子是玩具 MFC 应用程序与玩具 Cocoa 应用程序。后者微不足道地允许 MVC 风格的应用程序。
您一直在谈论 MVC，如果这就是规则或系统设计的全部内容。我知道 MVC 是什么，而业务规则的问题远不止于此。事实上，我会说大多数业务规则与视图完全无关，因此 MVC 不应该适用。

【解决方案4】：

答案取决于多个因素，例如

客户是否应该更改规则？
规则多久更改一次？
是否应该在不重新启动应用程序的情况下部署更新的规则？

如果以上所有问题的答案都是“是”，那么您正在寻找一个规则引擎（drools、ilog 等）来实施您的规则

如果您的答案是否定的，那么另一种方法是在代码中对规则进行建模，牢记以下内容

将 1 条业务规则封装在自己的类中，以便对其进行独立测试、定制和更新
以业务提及的方式命名规则（通用语言）
了解规范模式 (domain driven design)。我认为这种表达规则的方式非常直观和明确

例如复制自here

EligibleForDiscountSpecification isEligibleForDiscountRule = new EligibleForDiscountSpecification();
isEligibleForDiscountRule .IsSatisfiedBy(customer)

【讨论】：

你认为规范模式应该在什么时候使用？什么时候不使用？

【解决方案5】：

业务规则最佳实践规定规则应该是可插入的组件。一种极简主义的方法包括在专用库中对它们进行编码，然后继续进行依赖注入或反射……也许您也应该研究一下合同驱动开发，并查看www.businessrulesgroup.org/brmanifesto.htm 开始。

【讨论】：