在计算机软件中，业务逻辑（）也称为领域逻辑，是指根据现实世界的需求或所需的功能来编写的有关增删查改数据的代码。它编码了决定数据如何创建、存储和更改的
。与之相对的是软件的其余部分，如数据库管理、用户界面显示、系统基础设施或连接不同程序组件的底层细节。

与业务规则的区分
业务逻辑应与（business rules）加以区分。业务逻辑是决定数据如何转换、计算以及如何路由到人员或软件的流程（工作流），是过程性的。业务规则则是业务策略的正式表达，是声明性的——它们陈述「是什么」，而非「怎么做」。

例如，迎接一位新访客是一个流程（工作流）——包含需要采取的步骤；而规定「每位新访客都必须被迎接」则是一条业务规则。

示例
以一个电子商务网站为例，其业务逻辑可能包含以下结账工作流：

访客将商品添加到购物车；

填写收货地址；

填写账单地址；

选择支付方式；

页面显示确认信息。

业务规则则包括：

在商品详情页面将同一商品多次加入购物车，应递增数量而非重复添加；

地址、电子邮件和信用卡信息必须符合特定格式；

与信用卡网络的通信须遵循特定协议。

不属于业务逻辑的代码包括：定义页面颜色、外观和导航结构的HTML；显示HTTP 500错误页面的通用错误处理代码；服务器启动时的初始化代码；监控网站各部分是否正常运行的监控基础设施；以及建立网络连接、传输数据到数据库和解析用户输入等底层通用代码。

多层架构通过创建独立的业务逻辑层（business logic layer）来实现这种解耦。在模型-视图-控制器（MVC）模式中，业务逻辑通常集中在模型（Model）中。在电子商务示例中，控制器决定结账序列中的页面流程，并负责验证电子邮件、地址和支付信息是否符合业务规则，而不是将这些验证留给数据库本身。

工具与技术
业务逻辑可以使用（BRMS）从过程性代码中提取出来，从而实现更强制的分离。 领域模型（domain model）是对业务规则所需数据存储类型的抽象表示。所谓「魔法按钮」（magic pushbutton）被视为一种反模式——它产生不良约束，使业务逻辑难以以易于维护的方式编写。

参见
*

• 多层架构
• 模型-视图-控制器
• 业务流程建模
• 领域模型

参考文献