What really is the “business logic”?

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 seen 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 does this fit into an app? I know these are implemented as methods in domain models, but what could those methods possibly be, and where in the application they could possibly be used?

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

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.

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.

Whether you are using text files or a relational database, whether using a green-screen or a GUI, whether you are using magnetic tape or SSDs, what remains constant is the business rule about an invoice having at least one line item.

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.

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.

There’s always two separate things: What does the business, full of non software developers want to achieve? And how do you, as a software developer, make it all work?

“Business rules” are what your non-software developers tell you what your software needs to do. “Business logic” is the part of your code that specifically implements business rules. And in addition you write tons of code to make it all work, that the non-software developers know nothing about and don’t need to know anything about.

Now some businesses will see you as a stupid code-monkey who does as he is told. And others see you as a highly qualified person who can turn their wishes into reality. The first lot will expect you to implement their business rules without using your brain. The second one will know that even though you may not understand why specific business rules are there, as a software developer you can spot business rules that are contradictory, under specified or just pure nonsense from a mile away.

Say there’s a business rule that says “a customer’s account can’t become negative”. You’ll spot that this customer could submit two orders simultaneously and tell the business rules makers. What nobody in this thread noticed: if two deliveries have been made, exceeding the customers account, the account must go negative and you will inform the business rule makers to find out what tiles they want to apply in this unfortunate situations. You’ll spot business rules that will make customers switch to another company because you are a software developer who anticipates unwanted consequences. A good company will appreciate that kind of feedback.

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.

Filed under: softwareengineering - @ 07:54

Thẻ: object-oriented, object-oriented-design

Thiết kế website giá rẻ

Danh mục

What really is the “business logic”?

Transferring money from one checking account to another

Ordering something from Amazon.

Business Logic Is Portable