Oop 在代码中定义业务规则

一位程序员同事告诉我，我不应该在JSP中加入业务规则。这真把我弄糊涂了

我真的很难理解这一点。我的意思是，我不知道如何识别代码中的业务规则

问题：

什么是真正的商业规则？（我知道我可以在谷歌上搜索，但你能给我一个简单的例子吗？）

如何在代码中识别业务规则（最好举个例子）

---

业务规则只是一种编程逻辑，用于处理从数据库中提取的数据

---

业务规则不需要使用JSP实现。它应该使用Java编程逻辑创建，然后使用JSP显示数据。

业务规则是业务操作中用于指导行为、形成判断和决策的标准

大多数时候，我看到的是不同类型逻辑之间的混淆，它们都被错误地称为业务规则。您不应该在源代码中实现业务规则有很多原因。通常，应用程序应该处理不同类型的逻辑：应用程序逻辑和业务规则。当您将这些规则彼此分离时，就允许独立地更新业务规则，而不需要业务人员更改应用程序代码。例如，当税率发生变化时，业务部门可以更新税收规则，而无需询问IT团队（开发人员）

因此，在您的问题中，如果您仍然在JSP代码中保留业务规则，那么仍然存在对开发人员（和IT）的依赖性，因此我刚才提到的并没有多大好处。然而，在您的代码中以更好的方式进行结构化，将有利于项目的长期运行，所以开发人员将更容易地更新它们

如果您想完全从源代码中提取它们，并让它们在源代码（JSP）之外进行管理，那么您需要一个业务规则管理系统（BRMS）。BRMS的一个组件是，它允许您执行。 当我们谈论BRMS时，它不仅是执行（BRE）方面，而且还有其他功能，如标准建模语言和创作、调试、测试、版本控制、部署和托管为服务（REST）、安全性和权限控制等。。。因此，BRMS解决方案应该覆盖业务规则的整个生命周期

---

关于在代码中识别它们，IMHO，在现有应用程序中，识别和提取业务规则并不容易。这实际上取决于应用程序域的复杂性和编写的好坏。选择一个特定场景，与您的BA坐在一起，定义所实现场景的业务需求，检查逻辑是应用程序逻辑还是业务相关逻辑

与编程中的许多其他东西一样，一开始只是一个合理的指导方针，现在却变成了一个定义不清的规则，一根让书呆子用以打击无辜程序员的棍子

首先，没有人同意什么是业务逻辑。在天平的一端，你会遇到像@Arash这样的人，他们认为商业规则是由企业指定的，在他们的控制之下，比如销售税的确切税率。另一方面，有些人认为任何逻辑（比如检查sql返回代码）都可以作为业务逻辑。如果你正在为一家慈善医院实施一个系统，你怎么能完全不受任何“商业”规则的约束呢

为了简单明了，我敦促人们坚持以下定义。“由系统的请求者/客户指定的规则”因此，当项目发起人说“像这样计算销售税”时，这是一条业务规则，其他一切都是实现细节

其次，虽然在大多数情况下，将演示（如格式化屏幕、填充下拉列表等）与获取数据和计算数字分开是有意义的，但并不总是那么简单。如果有一条业务规则“不要让客户看到销售佣金数字”，该怎么办？如果有客户在场，您现在必须以不同的格式设置屏幕，这是在“演示逻辑”中最容易实现的规则。或者“使用我的交易者理解的彭博配色方案”，您可以在这个“业务逻辑”后端代码中跳过许多障碍来实现“绿色表示向上，红色表示向下，白色表示不变”，或者您可以在“表示逻辑”中使用一些简单易懂的代码

所以，除非你有一个很好的理由让你的JSP代码保持简单，只关注格式和表示。但是如果有一个很好的理由把逻辑放在那里，那就去做吧。一个简单的技巧是问问自己“作为一个语音呼叫中心应用程序实现这个功能有多容易？”