Business logic
业务逻辑
From Wikipedia, the free encyclopedia
来自Wikipedia，自由的百科全书
In computer software, business logic or domain logic is the part of the
program that encodes the real-world business rules that determine how data can
be created, displayed, stored, and changed. It is contrasted with the remainder
of the software which might be concerned with lower-level details of managing a
database or displaying the user interface, system infrastructure, or generally
connecting various parts of the program.
在电脑软件中，业务逻辑或者领域逻辑是指程序的一部分：它对真实世界中的业务规则进行编码，来限定怎样对数据进行创建、显示、保存和修改。与之相对的，软件的其他部分可能关心的是数据库的管理细节、显示用户界面、系统基础架构，或者如何把系统的不同部分连接起来。
Details and example
详情和范例
Business logic:
业务逻辑是指：
- Prescribes how business objects interact with one another
- 规定业务对象如何与另一个交互
- Enforces the routes and the methods by which business objects are accessed
and updated - 通过要被访问和更改的业务对象来指定路由和方法
Business rules:
业务规则是指：
- Model real-life business objects (such as accounts, loan, itineraries, and
inventories) - 对现实世界中的业务对象进行建模（比如账号、贷款、行程、库存等）
Business logic comprises:[1]业务逻辑包括：
- Workflows that are the ordered tasks of passing documents or data from one
participant (a person or a software system) to another. - 工作流，即一系列任务，它们把文档或数据从一个参与者（可以是人，也可以是软件系统）传递到另一个参与者。
Business logic should be distinguished from business rules. [2]Business logic
is that portion of an enterprise system that determines how data is transformed
or calculated, and how it is routed to people or software (=workflow). Business
rules are formal expressions of business policy. Anything that is a process or
procedure is business logic, and anything that is not a process nor a procedure
is a business rule. Welcoming a new visitor is a process (workflow) consisting
of steps to be taken, whereas saying every new visitor must be welcomed is a
business rule. Further, business logic is procedural whereas business rules are
declarative. [3]
业务逻辑不同于业务规则。业务逻辑是一个企业系统的一部分，它决定数据如何被转换或计算，以及如何被传递给人或软件系统（等价于workflow）。业务规则则是业务策略的一组公式化表达式。所有处理或过程叫做业务逻辑，既非处理又非过程的叫做业务规则。欢迎新的访问者是一个过程（工作流），它由一系列步骤组成，反之，“必须让每个新的访问者都感到受欢迎”，这是业务规则。更明确的说：业务逻辑是过程性的，而业务规则是描述性的。
For example, an e-commerce website might allow visitors to add items to a
shopping cart, specify a shipping address, and supply payment information. The
business logic of the website might include workflow such as:
比如一个电子商务网站可能允许访问者把东西添加到购物车中，指定一个发货地址，以及提供付款信息。这个网站的业务逻辑可能包括下列工作流：
- The sequence of events that happens during checkout, for example a
multi-page form which first asks for the shipping address, then for the
billing address, next page will contain the payment method, and last page will
show congratulations. - 在结账期间，下列事件序列将依次发生：比如，一个多页面表单首先会问用户发货地址，然后问账单地址，下一个页面将包括支付方式，最后的页面将显示“恭喜购物成功”的信息。
There will be also business rules of the website:
这个网站也包括了一系列业务规则：
- Adding an item more than once from the item description page increments
the quantity for that item. - 从物品描述页多次添加同一个物品，将增加这个物品的购买数量。
- Specific formats that the visitor‘s address, email address, and credit
card information must follow. - 访问者地址、邮件地址和信用卡信息必须按指定的格式填写。
- A specific communication protocol for talking to the credit card
network - 和信用卡网络“对话”时必须使用特定的通讯协议。
The web site software also contains other code which is not considered part
of business logic nor business rules:
这个网站软件还包括其他代码，它们不属于业务逻辑或业务规则的一部分：
- Peripheral content not related to the core business data, such as the HTML
that defines the colors, appearance, background image, and navigational
structure of the site - 与核心业务数据无关的次要内容，比如用于定义颜色、外观、背景图和网站导航结构的HTML
- Generic error-handling code (e.g. which displays the HTTP Error Code 500
page) - 通用的错误处理代码（比如显示一个HTTP的500错误）
- Initialization code that runs when the web server starts up the site,
which sets up the system - 网站服务器启动期间的初始化代码，它将引导系统
- Monitoring infrastructure to make sure all the parts of the site are
working properly (e.g. the billing system is available) - 用于监控的基础设施，用于确保网站的各个部分都在正常工作（比如账单系统有效）
- Generic code for making network connections, transmitting objects to the
database, parsing user input via HTTP POST events, etc. - 通用的网络连接代码、对象入库代码、通过HTTP的POST事件来解析用户输入的代码，等等。
Business logic and tiers/layers
业务逻辑和物理层/逻辑层
Business logic in theory occupies the middle tier of a 3-tier
architecture.
理论上，业务逻辑是三层架构中“中间层”的职责。
Business logic could be anywhere in a program. For example, given a certain
format for an address, a database table could be created which has columns that
correspond exactly to the fields specified in the business logic, and type
checks added to make sure that no invalid data is added.
业务逻辑可以出现在程序中的任何地方。比如，给出一个指定的地址格式，一个和业务逻辑中指定的字段相一致的数据表可能被创建，并且加入了类型检查来确保加入的数据必然有效。
（This section needs to be verified.）
（下面的部分需要进一步验证。）
Business logic often changes. For example, the set of allowable address
formats might change when an online retailer starts shipping products to a new
country. Thus it is often seen as desirable to make the code that implements the
business logic relatively isolated, or loosely coupled. This makes it more
likely that changes to business logic will require a small set of code changes,
in only one part of the code. Distant but strongly coupled code also creates
more of a risk that the programmer will only make some of the necessary changes
and miss part of the system, leading to incorrect operation.[4]
业务逻辑经常改变。比如，如果在线零售商开始支持往一个新的国家发货，那么允许的地址格式就需要改变。能让实现业务逻辑的代码相对独立或者松耦合的方案，通常会看起来比较漂亮。这将使业务逻辑的变化只需要改动少量代码。不够清晰的紧耦合代码将带来风险：程序员将只完成一部分修改，而其他的部分则被忘掉或略过了，这将导致错误的操作。
A multitier architecture formalizes this decoupling by creating a business
logic layer which is separate from other tiers or layers, such as the data
access layer or service layer. Each layer "knows" only a minimal amount about
the code in the other layers - just enough to accomplish necessary tasks. For
example, in a model–view–controller paradigm, the controller and view layers,
might be made as small as possible, with all the business logic concentrated in
the model. In the e-commerce example, the controller determines the sequence of
web pages in the checkout sequence, and is also responsible for validating that
email, address, and payment information satisfy the business rules (rather than
leaving any of that up to the database itself or lower-level database access
code).
多层架构通过创建业务逻辑层来把这种解耦工作正式化，它将从其他逻辑层或物理层中分离出去，比如数据访问层或服务层。每一层只“知道”其他层的一小部分代码 ——
只够完成必要的工作。比如，在一个MVC(model-view-controller)范式中，控制器和视图层被设计的尽可能小，所有业务逻辑被包含在model中。在电子商务的例子中，控制器决定结账流程中的页面顺序，并且它也负责规矩业务规则对邮件地址、地址、支付信息进行验证，并给出回应（但是把其他的部分留给数据库本身和数据访问代码）
Alternative paradigms are possible. For example, with relatively simple
business entities, a generic view and controller could access database objects
which themselves contain all the relevant business logic about what formats they
accept and what changes are possible (known as the database model)..
其他的范式也是可以的。比如，具有一个相对简单的业务实体，一个通用的、能自己访问数据对象的视图和控制器，它们包含了所有关于如何格式化所获得的数据以及允许做哪些改变（即数据模型）的业务逻辑……
Some tiered schemes use either a distinct application layer or a service
layer, or consider the business logic layer to be the same as one of those.
某些其他的分层方案可能使用一个明确的应用层、服务层，或把它们之一作为业务逻辑层。
Tools and techniques
工具和技术
Business logic can be extracted from procedural code using a business rule
management system (BRMS).[5]
业务逻辑可以从过程化代码中通过业务规则管理系统（BRMS）提取出来。
The business rules approach of software development uses BRMSs and enforces a
very strong separation of business logic from other code. User interface
management systems are another technology used to enforce a strong separation
between business logic and other code. The magic pushbutton is considered an
"anti-pattern": a technique that in this case creates undesirable constraints
which make it difficult to code business logic in an easy-to-maintain way.
使用BRMS系统近似于针对业务规则进行软件开发，并且把业务逻辑和其他代码强力分离开。“用户界面管理系统”是另一种把业务逻辑和其他代码强力分离的技术方案。“魔术推按钮”是一个反模式：在这种情况下，此技术创建了无法让人满意的约束，它无法使用易于维护的方式来编写业务逻辑代码。
A domain model is an abstract representation of the data storage types
required by business rules.
领域模型是业务规则中所需的数据存储类型的抽象表示。