在应用程序中究竟什么是"业务逻辑"？

我听过很多次,我们不应该将业务逻辑与其他代码或类似的语句混合在一起.我认为我编写的每一个代码(我的意思是处理步骤)都包含与业务需求相关的逻辑.

谁能告诉我究竟什么是业务逻辑？如何区别于其他代码？是否有一些简单的测试来确定什么是业务逻辑,什么不是？

只需用简单的英语定义您正在做的事情.当你在商业上说话时,比如"让那些受苦","偷钱","摧毁这部分地球",你在谈论商业层.为了说清楚,让你兴奋的事情就在这里.

当你说"在这里展示","不要表现出来","让它变得更美丽"时,你正在谈论表现层.这些都是让设计师兴奋的事情.

当你说"保存这个","从数据库中获取","更新","删除"等内容时,你所说的是数据层.这些东西告诉你不惜一切代价永远保留什么.

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

对我而言,业务逻辑是描述业务运营方式的规则,而不是软件架构的运作方式.业务逻辑也有变化的趋势.例如,每个客户都有一个与其帐户相关联的信用卡可能是业务要求.此要求可能会更改,以便客户可以拥有多张信用卡.从理论上讲,这应该只是对业务逻辑的改变,而软件的其他部分也不会受到影响.

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

纯粹主义者说,业务逻辑应该始终是完全独立的,因此甚至会反对在数据库中使用名为"Customers"或"Accounts"的表.采取极端的方式,你最终会得到一个令人难以置信的通用,不可能维护的系统.

肯定有一个强烈的论据支持将大部分业务逻辑保持在一起而不是在整个系统中涂抹它,但是(与大多数理论一样)你需要在现实世界中务实.

为了简化到一行...
业务逻辑将是不依赖/不会随着特定的UI /实现细节而变化的代码。它是规则，流程等的代码表示。由建模业务定义/反映。

我认为您将业务逻辑与您的应用程序要求混淆.这不是一回事.当有人解释他/她的业务逻辑时,它是这样的:

"当用户购买物品时,他必须提供交货信息.信息将通过xyz规则验证.之后,他将收到发票并获得积分,为y报价提供x%的折扣"(对不起的例子表示抱歉) )

实施此业务规则时,您必须考虑二级要求,例如信息的呈现方式,如何以持久的方式存储信息,与应用程序服务器的通信,用户如何收到发票等等.所有这些要求都不是业务逻辑的一部分,应该与它分离.这样,当业务规则发生变化时,您将更轻松地调整代码.这是事实.

有时,演示文稿会复制一些业务逻辑,主要是验证用户输入.但它必须也存在于业务逻辑层中.在其他情况下,有必要将一些业务逻辑移动到数据库,以解决性能问题.Martin Fowler 在此对此进行了讨论.