People use the terms “business rule” and “business logic” to refer to the portion of your application that is specific to your application and represents the core behavior of how things are supposed to work as opposed to generic functionality that could be useful in software written for a different client/business/customer base or code that exists to support the infrastructure of the application.

Often business logic is subject to change when the needs of the customer change, so we like to put it in a special place/tier so that we can modify it as needed.

Although the term seems to imply otherwise, non-business software also has business logic. For example, a rule that states that “when a user does xyz, the application should validate something” can be classified as a business rule.

Utility code, such as parsing/processing/data access and such would not be considered business logic.

It’s kind of a nebulous term and could mean different things to different people in different contexts. It’s not worth getting hung up on. The general idea is to separate your application into logical portions, each of which is responsible for something specific. How exactly this is done is something you learn from experience and working on well-designed large applications. But there aren’t any hard and fast rules. Ask three good developers and you’ll get six opinions.

Here’s an excerpt from Wikipedia:

It is a rule that defines or constrains some aspect of business and
always resolves to either true or false. Business rules are intended
to assert business structure or to control or influence the behavior
of the business Business rules describe the operations, definitions
and constraints that apply to an organization. Business rules can
apply to people, processes, corporate behavior and computing systems
in an organization, and are put in place to help the organization
achieve its goals.

With respect to what @aarong said, business rules or business logic doesn’t really mean you require some form of business entity to make this up.

This can mean any constraint or definition of a process that your application is supposed to do. These rules are meant to assert the behavior of your application and what it does.

For example, let’s put this logic in an ATM machine.

Business Rules could be:

• The user should have an ATM card
• The user should know the pin to the ATM card
• The amount the user is trying to withdraw shouldn’t exceed the account balance
• In case of any errors, revert any changes made to the system and reverse transactions if possible

Or in a more common place like Facebook:

• You need a Facebook account to login
• You must be logged in to add friends
• The user must be able to select who can see their posts and pictures
• The user should be notified about friend requests
• The user can accept or decline friend requests

Stuff like that.

Business rules are rules that exist in the problem domain that define or restrict processes in that domain.

These are rules that may be applied by software.

The use cases are documented observations of the business rules in practice.

Example, if the problem domain is prescribing, then:

1. a business rule could be “Can’t do refills on Control-II Medications”.
2. a use case or story could be “Patient requests refill on Medication… System denies refill because refills aren’t allowed on Control-II Medication…”

Business rules aren’t necessarily associated with computer applications.

When you see the term in a book, you can generally think of it as “Requirements” although requirements encompass more than just business rules.

You could call the business logic where you decide what you will do with the data that you got from the user. There you can manipulate it and return or save on database. What you do with that data depends on the client needs.