Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm working with web development since 2009, when I started with PHP. When I moved to ASP.NET I've heard a lot about DDD and OOAD where a lot of focus is given to this "business logic" and "business rules". The point is that all the apps I've developed until now were all about CRUD operations and I've never seem these things in practice.

I simply can't imagine what those things can really be in practice. So, what really is this business logic and how this fits into an app? I know these are implemented as methods in domain models, but what those methods could possibly be, and where in the application they could possibly used?

share|improve this question

6 Answers 6

up vote 51 down vote accepted

CRUD is an acronym that stands for Create, Read, Update and Delete. Those are the four basic operations that you can perform on a database tuple. But there's always more to business applications than creating, reading, updating and deleting database records.

Let's start with some basic definitions, and then look at a couple of examples and see how those definitions map to the examples, and how they map to actual software.

Business logic or domain logic is that part of the program which encodes the real-world business rules that determine how data can be created, displayed, stored, and changed. It prescribes how business objects interact with one another, and enforces the routes and the methods by which business objects are accessed and updated.

Business Rules describe the operations, definitions and constraints that apply to an organization. The operations collectively form a process; every business uses these processes to form systems that get things done.

Now, let's work with some examples.

Transferring money from one checking account to another

First, what are the things that you need to know (input)?

  • The identity of the person making the transfer
  • The amount of money to be transferred
  • The source checking account number
  • The target checking account number

What are some of the "business rules" that must be applied?

  • The person making the request must have the authority to do so.
  • The transaction must be atomic.
  • The transaction may have reporting requirements to the government, if it is over a certain amount

By "atomic," I mean that the transaction must completely succeed or it must completely fail. You can't have account transactions where money is taken out of one account without arriving in the other (money disappears), or money is deposited into an account, but not debited from another account (money magically appears from nowhere).

Ordering something from Amazon.

What do you need to know?

  • The identity of the person ordering
  • Shipping information
  • Billing information
  • Method of Payment
  • Amount and quantity of each item to ship
  • How to ship (overnight, slow boat or super saver)
  • State Tax Rate

What happens after the order is placed?

  • Items are pulled from stock
  • On hand quantities are debited
  • Items are packaged for shipment
  • Out of stock items are backordered
  • Items that drop below minimum quantities are ordered
  • One shipment or two?
  • An invoice/shipping list is printed, and placed with the order

    ..etc.

share|improve this answer
    
I like the definitions but in the examples, I miss the distinction you make between business logic versus business rules. –  jdv-Jan de Vaan Mar 31 at 17:51
    
Business logic refers to code. Business rules refers to the business. –  Robert Harvey Mar 31 at 17:52
5  
@jdv: You're overthinking this. Would a teller only perform half of that transaction? –  Robert Harvey Mar 31 at 17:59
1  
@jdv: Saying that the transaction must be atomic implies two things: (1) if something interferes with the processing of the transaction, it will be possible to either undo any effects of the transaction as though it never occurred (except, perhaps, for the creation of an error-log report), or else complete everything that needs to be done; (2) no part of the transaction will overlap any other "atomic" transaction involving those accounts. For example, if someone who has $1,000,000 in each of two accounts transfers $500,000 from one to the other at the moment that the bank is asked... –  supercat Mar 31 at 18:24
2  
@jdv transaction being atomic is a fundamental requirement which needs to be ensured and relates to an end-state. –  icarus74 Apr 1 at 2:45

Other answers are correct. One additional thought…

Business Logic Is Portable

If you were to re-implement a software project in a different programming language, say moving from Turbo Pascal to Java, business logic & business rules is what the old and new projects would have in common.

The programming language would be different. The source code would be entirely different. The tools (IDEs, compilers, and such) might be entirely different. The user interface might be entirely re-organized or have a different look-and-feel. The documentation would probably be different. But the purpose of the two projects, the end results of work performed / goals accomplished, would be the same.

share|improve this answer

Business logic or rules are anything that don't pertain to the mechanics of the user interface (the "programming stuff"). They are the things you would still have to apply if you were doing this transaction or whatever 100 years ago (manually). For example, when to apply sales tax to a purchase.

share|improve this answer

Business logic basically consists of 2 broad categories: validation and flow. Business logic says that qty 1 must be greater than or equal to qty 2 -- for example, number of items to purchase must be less than or equal to number of items in stock.

In one application, the business folks will say this is a business rule, and so you write code to enforce this business logic(validation). Another application will say that if the number of items ordered is greater than the numbers of items in stock, to accept the order and then to place your own order for the difference plus 20%, and so you will write this business logic(flow).

CRUD is simply getting data in and out storage and changing it. Business logic determines what you do with that data and what transformations you are allowed to make to it. Is your customer born in the future, under 5, from a certain geographical area (discounts for locals/visitors). CRUD is simple, knowing that you can get a child tax credit only if the child lived with you for more than half of the time it was alive in the calendar year NOT just more than 6 months, is more complex.

share|improve this answer

The "business logic" of a program or application is the part of the code that actually does things with input (from the user, the operating system, and etc). The "business rules" of an application is usually the defined parameters of the program itself (such as how to handle input). At least, this is how I have heard it referred to from many people. They are pretty much similar terms to describe parts of the code.

share|improve this answer

CRUD is simply the Create, Read, Update, Delete that an application does.

To an extent, a bug tracker is a CRUD app too. Create bugs, Read (display) the bugs, Update the bugs, and maybe, delete them.

However, there is more to a bug tracker than just CRUD.

  • A developer isn't allowed to mark the bug verified or closed - thats part of QA's job. And so some code is in there to make sure that someone who lacks the role of QA can't mark a bug as closed or verified.
  • No one but a project manager can actually delete a bug.
  • In order for a bug to be marked as "test me", there must be at least one commit of code against the bug.
  • Only a bug that is in the 'closed' state may be moved to the 'reopen' state
  • The developer assigned to the bug cannot move it from 'code review' to 'code review complete'
  • QA and Developers can only see bugs on projects they are assigned to.

The code that implements the above is the business logic of the application.

The restriction of workflows, or who can do the various operations in CRUD. These are what separates one CRUD app from another. They are the parts where you need to get the business to actually say how the application works. How logical it is... well, thats best discussed over a beer out of the earshot of the project manager. But thats what business logic is.

Sure, its possible to write a 'pure' CRUD app where there are no roles, everything can be modified and viewed - but these are the exception rather than the rule.

The business logic is the logic that you are writing into your program to handle the business rules that you are given.


When you start getting into business rules, this tends to be be at a higher level than crud itself or business logic. This tends to be the things you get from a business analyst who is working with the business.

Consider in this example, a program that determines how to handle the return of an item at a returns desk in a store.

  • If the receipt is equal to or more than 90 days old, only in store credit may be given
  • If the receipt is less than 90 days old, credit the tender that the receipt was used to purchase with (credit goes back on the credit card, cash goes back to cash, in store credit goes to in store credit)... unless it was a check, in which case use cash.

Those are some business rules. They don't speak to the CRUD part of the application.

When working with business rules, you may often find these written in a rules engine (for example, Windows Workflow Foundation Rules Engine) instead of writing the raw code in your system.


Realize that the logic / rules distinction is one of terminology and can be argued all night long (best over a beer again). Though this isn't an uncommon distinction, though the two can blend into each other.

share|improve this answer

protected by gnat Apr 1 at 11:03

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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