I'm trying to better organize my application architecture, so I've been doing some reading, but I keep running into references to "Business Logic" and "Business Rules". I've never really understood what these actually are. I generally just focus on Use Cases and "User Stories". Could someone explain what Business Logic and Business Rules are, and how they are related to Use Cases?

All the definitions I've found seem to pertain to actual businesses, not software development.

Because software is not always representative of a business, does that mean that software does not always have business logic? Or...


4 Answers 4


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.

  • 2
    Thanks, that's a really helpful explanation. I was struggling to understand a portion of a talk about architecture where the speaker stated that ".. this part handles your business rules" ( or something to that effect ).
    – hal
    Oct 30, 2014 at 0:10
  • 4
    Nice explanation. Two clear examples might be useful. 1. Tax rules are a clear example of business rules. 2. A transaction count would be an implementation detail. I would also add that sometimes businesses have "business rules" that are artifacts of previous system implementations, whether computer or manual. They become part of the business process, and can easily be perpetuated without deep understanding for their purpose.
    – andy256
    Oct 30, 2014 at 2:02
  • @andy256 - both good points, thanks. Tax rules are a good example of business logic in business software, OP seemed to wonder how business logic might be used in consumer-software. But your example is helpful nonetheless. Oct 30, 2014 at 2:18
  • Ask me and you'll get up to six opinions. Business rules are fickle at best, even when based on laws or procedures. The precise circumstances will depend on who's asking, what's being done, and what policies are in effect. Rules are not meant to be broken, and so business rules often dictate things that otherwise often don't make sense-- because some law requires it or some policy forbids it, whatever "it" may be.
    – phyrfox
    Oct 30, 2014 at 5:34
  • 1
    I like this definition. I always imagined business rules to be your application specific. When making a software you have code (modules, classes) that deal specifically with your application (or business) and there are code that are agonostic to your application (or business). Ex: Say I have a business of selling cakes online. My online store has specific requirements that are related to selling cakes. On the other hand, I have a lot of infrastruture, web framework code, that are not specific to my business - they are generic, application agnostic and can be used by other businesses.
    – Sa'ad
    Oct 13, 2022 at 13:34

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.

  • 2
    Do you have any supporting references for your statement? Oct 29, 2014 at 23:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.