What exactly consists of 'Business Logic' in an application?

Question

I have heard umpteen times that we \'should not mix business logic with other code\' or statements like that. I think every single code I write (processing steps I mean) con

Answer 1

For me, " business logic " makes up all the entities that represent data applicable to the problem domain, as well as the logic that decides on "what do do with the data"..

So it should really consist of "data transport" (not access) and "data manipulation".. Actually data access (stuff hitting the DB) should be in a different layer, as should presentation code.

Answer 2

It's probably easier to start by saying what isn't business logic. Database or disk access isn't business logic. UI isn't business logic. Network communications aren't business logic.

To me, business logic is the rules that describe how a business operates, not how a software architecture operates. Business logic also has a tendency to change. For example, it may be a business requirement that every customer has a single credit card associated with their account. This requirement may change so that customers can have several credit cards. In theory, this should just be a change to the business logic and other parts of your software will not be affected.

So that's theory. In the real world (as you've found) the business logic tends to spread throughout the software. In the example above, you'll probably need to add another table to your database to hold the extra credit card data. You'll certainly need to change the UI.

The purists say that business logic should always be completely separate and so would even be against having tables named "Customers" or "Accounts" in the database. Taken to its extreme you'd end up with an incredibly generic, impossible to maintain system.

There's definitely a strong argument in favour of keeping most of your business logic together rather than smearing it throughout the system, but (as with most theories) you need to be pragmatic in the real world.

Answer 3

Business logic is pure abstraction, it exists independent of the materialization/visualization of the data in front of your user, and independent of the persistence of the underlying data.

For example, in Tax Preparation software, one responsibility of the business logic classes would computation of tax owed. They would not be responsible for displaying reports or saving and retrieving a tax return.

---

@Lars, "services" implies a certain architecture.

Answer 4

I dont like the BLL+DAL names of the layers, they are more confusing than clarifying.
Call it DataServices and DataPersistence. This will make it easier.

Services manipulate, persistence tier CRUDs (Create, Read, Update, Delete)

Answer 5

I think you confusing business logic with your application requirements. It's not the same thing. When someone explains the logic of his/her business it is something like:

"When a user buys an item he has to provide delivery information. The information is validated with x y z rules. After that he will receive an invoice and earn points, that gives x% in discounts for the y offers" (sorry for the bad example)

When you implement this business rules you'll have to think in secondary requirements, like how the information is presented, how it will be stored in a persistent way, the communication with application servers, how the user will receive the invoice and so on. All this requirements are not part of business logic and should be decoupled from it. This way, when the business rules change you will adapt your code with less effort. Thats a fact.

Sometimes the presentation replicates some of the business logic, mostly in validating user input. But it has to be also present in the business logic layer. In other situations, is necessary to move some business logic to the Database, for performance issues. This is discussed by Martin Fowler here.

Answer 6

To simplify things to a single line...
Business Logic would be code that doesn't depend on/won't change with a specific UI/implementation detail.. It is a code-representation of the rules, processes, etc. that are defined by/reflect the business being modelled.