如果不是“所有非第三方代码”，“业务逻辑”实际上意味着什么？

我听说人们经常在工作中和在线上谈论业务逻辑，并且我已经在此站点上阅读了一些有关它的问题，但是这个词对我来说仍然没有多大意义。例如，以下是我经常看到的一些（释义）语句：

• “业务逻辑是程序中编码实际业务规则的部分。” 我读过的大多数定义都是这样的循环定义。

• “业务逻辑是您的特定应用程序所独有的一切。” 我不认为这与“您的特定应用程序不过是业务逻辑”有什么不同，除非我们不小心重新发明了一些轮子，可以使用现有的第三方软件。因此，问题标题。

• “在数据访问层上方和GUI层下方应该有一个业务逻辑层。” 在我编写的代码中，数据库访问者必须知道他们应该访问什么数据，UI代码必须知道很多关于其显示内容的信息才能正确显示，这之间没有任何实际要做的事情。除了在客户端和服务器之间传递数据Blob之外，还有这两个地方。那么，实际上应该放入业务逻辑层的内容是什么？

• “业务逻辑应与表示逻辑分开。” 我们收到的大多数功能请求都是出于业务原因更改展示逻辑。如果业务规则之一是默认情况下以32位符号显示美国政府债券价格（同时还为用户提供配置UI的功能），则表示逻辑至少需要知道该规则存在（如果未完全实现）。而且，UX设计的主要部分似乎是帮助用户了解我们的软件试图实现的业务规则。

我是否有可能实际上只在一个只包含业务逻辑的团队中工作，而所有非业务逻辑都由其他团队来完成？还是“业务逻辑”作为一个单独实体的整个概念仅适用于某些应用程序或体系结构？

为了使答案更具体：假设您必须重新实现Domino的Pizza应用程序。什么是业务逻辑，该应用程序的非业务逻辑是什么？以及如何在不将大多数披萨信息渗入数据访问和表示层的情况下，将披萨订购业务逻辑放入其自己的代码“层”中？

更新：我得出的结论是，我的团队可能正在执行90％的UI代码，并且您所称的大多数（但不是全部）业务逻辑都来自其他团队或公司。基本上，我们的应用程序是用于监视财务数据以及几乎所有功能都是用户自定义其所见以及所见方式的方式。没有进行买卖（尽管我们与公司的其他应用程序进行了一些集成），并且实际数据由大量外部资源提供。但是我们确实允许用户执行诸如将其“监视器”的副本发送给其他用户之类的事情，因此我们处理方式的详细信息可能符合业务逻辑。实际上，目前有一个移动应用程序正在与我们的一些后端代码进行对话，并且我确切地知道我希望在理想的世界中与我们的UI共享前端代码的哪一部分（基本上是准MVC中的M），因此我猜这就是我们的BLL。

我接受user61852的回答，因为它使我对“业务逻辑”指的是和不指的有更具体的了解。

我不会给您一些有关CRUD应用程序的提示，因为我在游戏或图形密集型应用程序方面没有太多经验：

• 业务逻辑通常涉及业务所有者在多年的经营过程中了解或决定的规则，例如：“如果客户尚未完成最后一笔付款，则拒绝任何新的信用额度”或“我们不出售早餐” “上午11点”或“周一和周二，客户可以以一个的价格购买两个比萨”。
• 当然，表示层必须显示一条消息，指示是否有折扣或拒绝退款的原因，但是该层并不能决定这些事情，它只是向用户传达幕后发生的事情。
• 业务逻辑通常涉及一个工作流，例如：“该项目必须在3个工作日内由某个经理确认或进入“信息请求”阶段，如果客户未提交所需的文档，则该项目将被拒绝”。。
• 表示层通常不处理这种工作流程，它仅反映工作流程的状态。
• 而且，数据访问层通常很简单，因为业务逻辑已经做出了决策。例如，当您决定将数据从MS SQL Server迁移到Oracle时，此层会受到影响
• 的确，有时GUI会进行一些验证以避免对服务器的调用，但这应该明智地进行，否则您可能在该层中拥有很多业务逻辑。
• 大多数困惑可能是由于您的应用程序中没有关注点分离并且实际上在表示层中有太多业务逻辑而引起的。您（错误地）在应用程序层或数据访问层中具有业务逻辑这一事实并不会改变其为业务逻辑的事实。
• 在公制中显示距离而不是英里/码/英尺等东西不是表示逻辑，而是业务逻辑。业务层必须以必需的单位返回数据，并告诉表示层要处理的单位以显示适当的标签，但这绝对是业务逻辑问题。
• 业务逻辑不应受到以下事实的影响：您现在使用的是Oracle而不是Postgres，或者公司更改了徽标或样式表。
• 无论您是否通过编写应用程序使其自动化，都存在业务规则。即使企业使用诸如笔和纸的低技术解决方案，也可以强制执行这些规则。
• 如果您拥有桌面应用程序的移动版本或网络版本，则这些版本中的每一个都有不同的表示层，但（希望）是相同的业务层。

听起来您的大部分工作可能都在UI层中。由于业务原因更改显示格式，并不表示任何业务逻辑。更改是对视图逻辑的更改。

能够更改格式意味着某些业务逻辑可能涉及偏好的持久性。

将格式保留为cookie的方法也可以在视图层中实现。

但是，这可以以MVC方式实现。（某些模型将视图实现为能够处理首选项的自己的MVC。）

• 用户的首选项可以由模型（数据库/ cookie）存储。
• 控制器将通过更改模型中的用户偏好来响应格式请求。
• 视图将调整为用户的首选项。可以从模型中请求首选项，也可以由控制器提供首选项。

对您的应用进行有根据的猜测。

• 有一个模型，其中包含可用的债券以及它们的定价数据。
• 有一个视图允许用户查看他们可以做的各种事情：搜索债券，显示价格，比较收益，接受定单，并显示业务模型根据请求返回的结果。

• 业务逻辑处理以下内容：

  • 执行搜索并提供视图显示。
  • 查找债券的价格并提供要显示的视图。
  • 比较产量并提供数据以供视图显示。
  • 处理订单并将其存储在模型中。

如果做对了，应该可以在不更改模型或业务逻辑的情况下提供多个视图组件。例如，如果当前设计是网站，则用于iPhone或Android应用程序的新视图服务器将使用现有模型和业务逻辑。这些可能会引入新的业务功能，以在订单完成时提供推送通知，这可能需要更改多层。

此故障可以将关注点分离。

• 由模型表示的数据层趋于相对稳定。
• 业务层是应用业务决策的地方：是否可以满足请求？是否已获得所有必需的数据？用户被授权吗？交易中是否有任何危险信号？
• 视图层趋于不稳定，并且可能不止一个。这是应用程序外观所在的位置。可以完全对应用程序重新设置外观，而无需更改其他层。