Design patterns 将规则应用于事实的设计模式和算法
我正在努力确定客户对零售环境中定价引擎的要求。我们已经将定价引擎定义为在一组定价规则上运行，这些规则基于购物车中已有的商品为购买的商品建立新的价格点 一个简单的价格规则可能是给衬衫打八折。 一个更复杂的规则可能是，当你买两条裤子并至少花30美元时，你可以得到一件免费的衬衫 应用这些规则的一般行业惯例似乎是对客户的最终最佳价格，但现在看来，可能需要一个排名选项和一个堆叠选项 排名将允许一个规则，否则将失去胜利。堆叠将允许多个规则获胜 我已经阅读了很多关于规则引擎的帖子，我需要帮助确定我是否应该将这些工具中的一个作为我设计的一部分，或者如果不是，哪些设计模式和算法可能适用于设计Design patterns 将规则应用于事实的设计模式和算法,design-patterns,rules,Design Patterns,Rules,我正在努力确定客户对零售环境中定价引擎的要求。我们已经将定价引擎定义为在一组定价规则上运行，这些规则基于购物车中已有的商品为购买的商品建立新的价格点 一个简单的价格规则可能是给衬衫打八折。 一个更复杂的规则可能是，当你买两条裤子并至少花30美元时，你可以得到一件免费的衬衫 应用这些规则的一般行业惯例似乎是对客户的最终最佳价格，但现在看来，可能需要一个排名选项和一个堆叠选项 排名将允许一个规则，否则将失去胜利。堆叠将允许多个规则获胜 我已经阅读了很多关于规则引擎的帖子，我需要帮助确定我是否应该将这
很明显，这可能是一个NP问题，我将处理的项目（事实）数量可能超过每笔交易100多个，每次添加新项目时都需要重新定价。规则引擎非常合适。如果规则引擎是可靠的，适合您的体系结构/应用程序的其余部分，并且是您的应用程序的核心功能所需要的，那么就使用它 如果规则引擎只是应用程序的一小部分，甚至更糟：是一些代码，它与应用程序的其余部分不同。。。那你应该重新考虑。每个应用程序部分，都是核心应用程序的外部部分（甚至数据库也是java应用程序的外部部分），都是一种风险
然后有两种可能：自己编写一个简单的规则引擎，或者利用策略或状态模式。Martin Fowler有一篇关于规则引擎以及在何处使用它们的文章。看看是否有帮助
我正在调查此事。我读过他的作品集，但最近没有浏览他的在线资料。好奇的是，你最终选择了哪种方法？这是正确的选择吗？我们创建了自己的规则引擎，最终使用了多种技术来解决问题。我没有现成的信息可以在这里分享，因为这是在7年前解决和实施的。我们最终使用了某种本地化方法，并对本地化应用了权重。然后，我们使用最小成本路由类型的算法来确定价格交易的最佳组合。最终完成的工作是我最喜欢的项目之一——我们将其作为一个独立的模块编写，可以在其他地方使用。规则+输入集->定价输出集。