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?

6 Answers
6

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.

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).

I like the definitions but in the examples, I miss the distinction you make between business logic versus business rules.
–
jdv-Jan de VaanMar 31 '14 at 17:51

Business logic refers to code. Business rules refers to the business.
–
Robert HarveyMar 31 '14 at 17:52

5

@jdv: You're overthinking this. Would a teller only perform half of that transaction?
–
Robert HarveyMar 31 '14 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...
–
supercatMar 31 '14 at 18:24

2

@jdv transaction being atomic is a fundamental requirement which needs to be ensured and relates to an end-state.
–
icarus74Apr 1 '14 at 2:45

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.

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.

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.

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.

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.

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.