应用程序中的“业务逻辑”到底由什么组成？

我已经无数次听到我们"不应将业务逻辑与其他代码混合"或类似的声明。 我认为我编写的每个代码(我指的是处理步骤)都包含与业务需求相关的逻辑。

谁能告诉我到底什么才是业务逻辑？ 如何将其与其他代码区分开？ 是否有一些简单的测试来确定什么是业务逻辑，什么不是？

---

只需用简单的英语定义您在做什么。当您以商业眼光谈论事情时，例如"让那些人受苦"，"窃取金钱"，"摧毁这部分土地"，您所谈论的是商业层面。明确地说，让您兴奋的事情就在这里。

当您说"在这里显示"，"不要显示"，"使其更美观"时，您是在谈论表示层。这些使您的设计师兴奋不已。

当您说诸如"保存此"，"从数据库获取此"，"更新"，"删除"等之类的内容时，您正在谈论数据层。这些都是告诉您不惜一切代价永远保留的东西的事情。

---

从说什么不是业务逻辑开始可能更容易。数据库或磁盘访问不是业务逻辑。 UI不是业务逻辑。网络通信不是业务逻辑。

对我而言，业务逻辑是描述业务运作方式而不是软件架构运作方式的规则。业务逻辑也有变化的趋势。例如，可能有一个业务要求，即每个客户都必须拥有与其帐户关联的一张信用卡。此要求可能会更改，以便客户可以使用几张信用卡。从理论上讲，这仅是对业务逻辑的更改，并且软件的其他部分不会受到影响。

这就是理论。在现实世界中(正如您所发现的)，业务逻辑倾向于在整个软件中传播。在上面的示例中，您可能需要向数据库中添加另一个表来保存额外的信用卡数据。您当然需要更改UI。

纯粹主义者说，业务逻辑应该始终完全分开，因此甚至反对在数据库中使用名为" Customers"或" Accounts"的表。
极端到极点，您最终将获得难以置信的通用性，无法维护系统。

肯定有一个强有力的论据支持将您的大多数业务逻辑放在一起，而不是在整个系统中涂抹它们，但是(与大多数理论一样)您需要在现实世界中务实。

---

我认为您将业务逻辑与应用程序需求混为一谈。不一样当某人解释其业务逻辑时，它类似于：

"当用户购买商品时，他必须提供送货信息。该信息将通过xyz规则进行验证。此后，他将收到一张发票??并获得积分，这将为y优惠提供x％的折扣"(抱歉，这个不好的例子)

实施此业务规则时，您必须考虑一些次要要求，例如信息的显示方式，信息的持久存储方式，与应用程序服务器的通信，用户如何收到发票等。所有这些要求都不是业务逻辑的一部分，应该与其分离。这样，当业务规则更改时，您将花费更少的精力修改代码。这是事实。

有时，演示文稿会复制一些业务逻辑，主要是在验证用户输入中。但是它也必须存在于业务逻辑层中。在其他情况下，有必要将一些业务逻辑移至数据库，以解决性能问题。这是Martin Fowler在这里讨论的。

---

要将事情简化为一行...
业务逻辑将是不依赖/不会因特定的UI /实现细节而更改的代码。
它是规则，流程等的代码表示，这些规则，流程等由建模业务定义/反映。

---

我不喜欢这些图层的BLL + DAL名称，它们比澄清更令人困惑。
将其称为DataServices和DataPersistence。这将使其更容易。

服务操纵持久层CRUD(创建，读取，更新，删除)

---

业务逻辑是纯抽象的，它的存在独立于用户面前数据的实现/可视化，并且独立于基础数据的持久性。

例如，在税务准备软件中，业务逻辑类的一项职责是计算所欠税款。他们将不负责显示报告或保存和检索纳税申报单。

@Lars，"服务"表示某种体系结构。

---

如果它包含有关表单，按钮等内容的任何内容，则不是业务逻辑，而是表示层。如果它包含对文件或数据库的持久性，则为DAL。介于两者之间的是业务逻辑。实际上，非UI有时会被称为"业务逻辑"，但这应该是与问题领域有关的，而不是与内部管理有关的事情。

---

对我来说，"业务逻辑"构成代表适用于问题域的数据的所有实体，以及决定"对数据做什么"的逻辑。

因此，它实际上应该由"数据传输"(不是访问)和"数据操纵"组成。实际上，数据访问(东西碰到DB)应该在不同的层中，表示代码也应该在不同的层中。

---