What The Heck Is Business Logic Anyway?

Hi Ben,
It's none of my business to comment on your programmer frustration since I know very, very little about programming. (Though, I'm much interested in it). However, I started following you a while ago on Facebook after reading your blog. I like your writings.
But, to return to why I respond here in the first place, besides telling you that I like reading your blog and that the title of this one caught my eye tonight on FBs startpage, next to the phrase that you're posting for the first time in months (I'm a blogger as well and didn't post new blogs for months either, which I miss actually a lot)is that you made me curious about the phrase "business logic".
The first thing I thought (as being a non-programmer) was that it must have had something to do with business-like manners. Meaning short, to-the-point, and profitable. The second thing was, let's see what google say about it. Maybe Dutch google would pop up the answer you're looking for. And pro's probably skip the results google returns which seem to obvious. To be honest, the idea to be showered with all kinds of awesome praises was partly why I did that :)
Business-logic is defined on Wiki and there was a link to Business-rule-management system. Then I was lost already. I have not the slightest bit of hope that you don't already know what's written there. So much for the awesome praises.
However, I do hope that someone will seriously help you to tackle this question and that you won't be frustrated any further by my reply. Frustrations in general are not very helpful to find the answers you're looking for. But hey, that's my topic, as being a psychology student ;)

Best wishes,
Debby

I couldn't agree more. I'm anxiously waiting to see how people weigh in on this topic.

Ben, I found the accepted answer to this SO question to be a concise answer to your question:

http://stackoverflow.com/questions/2630758/whats-the-difference-between-application-layer-and-business-logic-layer

My understanding of the answer, from an MVC perspective, is that the "Model" is the layer that contains the business logic. In a perfect world (i.e., never), the model could be plugged into any framework and it would just work because it doesn't care about the way it's being used in the application. In this case, the application logic would be contained in the "Controller" layer of our application. The business logic doesn't need to know how it's being used by the application, and the application logic doesn't need to know what the business logic is doing.

I don't think this necessarily lends itself to a "God Object," unless you would consider the controller itself to be that object. The application layer knows all the rules and how these rules interact (user must be logged in, name cannot be empty), but it doesn't know how to determine if the rules are being broken - it only knows who to ask to find out if they are being broken. On the other hand, the business layer is there to tell you if a rule is being broken, but it doesn't need to know the overarching goal of evaluating that single rule - it just checks if the user is logged in, but it doesn't know that that is one of a dozen rules that has to be run before a post can successfully be renamed.

I feel like I rambled a bit there, so (anyone) please feel free to poke holes in it. Also, I may be 100% wrong in which case I would love to hear any rebuttals. :)

In my head, the divide between Business and Application logic is this: Business logic manages data, Application logic manages users. If your system was never touched by users (such as an automated system, like an ETL process) there would be little or no Application logic. If your data had no structure and no rules (think JSON data store) there would be little to no Business logic.[1]

Sure, there will sometimes be overlap, but the key is to figure out if you're trying to keep the user from doing something dumb/unauthorized, or if you're trying to ensure your data doesn't degenerate into useless entropy.

I also find that Application logic may involve state ("the user must be logged-in and an admin", "this request should be cached") whereas Business logic usually doesn't. (Unless you want to be pedantic and call setters "state mutators", but that's just being obtuse.)

I remember an argument years back in which someone (maybe Hal Helms or Sean Corfield) very smartly asserted that objects (and by extension data) should never be able to exist in an invalid state. The stuff that ensures that is the case is Business logic.

--
1. Yes, a JSON data store still has Business logic in the form of validating that incoming data is correctly-formatted JSON, but you get my point.

Here are what would go through my mind for deciding where to implement the business logic.

Purely manipulating properties of the object itself?
> Implement in a method of the object class.

Front-end dependent?
> Implement in the handler layer of your MVC framework.

Complex task that needs other services to complete?
> Implement in a service where it is easy to hook up to other services through dependency injection. Make sure the sub-tasks are implemented in the appropriate services. Aim for readability over everything. You may also consider inject the service back to the object through a factory if the task makes sense to be exposed as obj.doTaskX(). Once things are working, spend the time to re-factoring until the code is easily readable and the flow of sub-task can be traced clearly.

Thanks for a thought provoking post-- takes me back to early VB days when "n-tier" programming with Microsoft products was all the rage. Funny part is, I don't recall hearing anyone use the phrase "business logic" in the entire time I've done web programming.

If you'd asked me to explain "business logic" back then, I'd have said something like "it's where you capture requirements that are unique to this client/department to keep them separate from the parts that can be reused in other projects." So, for example, all applications have user accounts that require passwords to authenticate-- but the password policies for a valid/strong password will be different from one department to the next, so that's a "business rule" you would capture in your middle tier. This leaves your first tier free for reuse with different "business rules" in other applications.

I could be full of nonsense, of course, but that's my recollection of how it was explained to me.

Ben -- I can definitely understand your frustration! With things like overloaded terms, misused terms, differing experiences, and changing technology, it sure gets confusing out there. Thanks for providing a concrete example for discussion. Here's how I've often seen the division of responsibilities between the application and business layers decided.

Looking at the individual steps that you've identified, we can group the specific lines into these broader categories.

1. Make sure the user is authorized to rename this thread
2. Make sure that the thread is able to be renamed
3. Make sure that the new thread name is valid
4. Change the name
5. Send notifications

This high-level list hopefully conceptually includes everything you've got in your lists above, just with a little less detail. If I were writing an application layer, I'd start by putting these five statements into it. In other words, each of these five steps would be (roughly) a single call to some domain object, or maybe to another service.

Then, the actual implementation of each of these five steps would go into the business layer. That way, the application layer is orchestrating the domain model (i.e., making the calls into it) but not doing the actual work.

From there, you might choose to move small bits of code up into the app layer or down into the domain. For example, it'd probably make sense to have the name validation done as part of the call to thread.rename().

Naturally, you can slice up the code in all sorts of different ways and still get the same functionality. A good design is defined by how well it serves you as the programmer, today and in the future. So if using a domain model isn't a natural fit for the app, I wouldn't force it.

Does that help at all?

Hey Ben,

This is a very very interesting question you ask. What is "Business Logic". Well within the last year working in my company I got to know what business logic is (at least for the company I work for)

So before I started working at Pepsi I had no concept of what business logic was. But the way it was explain to me by our senior analyst is that "Business Logic" is the way the Business manages, calculates, or uses data. This "logic" is presented to the Developer {me} in a set of requirements. The Developer {me} takes the requirements and implements them in the application.

So for example for the last year Pepsi has created several metrics for measuring efficiency for all their plants that manufacturer and bottle soda and water.

So the business creates different metrics that measures the rate of the machines, the people on staff, any stoppage of production given specific reasons which helps them determine how efficient that plant is running.
Now as a developer that has not been in the plant, I have no way of knowing what those measures are for calculating efficiency and what I should be looking for. I depend on the Business team (which are business analyst that already track these things in Excel Spreadsheets) to give me that information so I can correctly implement it into the application that I will be updating.

So in my case "Business Logic" are a set of requirements that reflect the current business practices.

My example is different from yours and I imagine others who are in a different line of business. Your business is programming and is where I'm assuming it makes its money from, I work for a company who sells a product and the IT department is just a part of it, but not the main part.

But Like Sean Walsh mention in the comments about MVC which is a framework my company uses. We will implement the business logic in the "Model". Currently I'm doing that through the use of Stored Procedures that generate reports for the user through and desktop application.

http://www.jcorporate.com/expresso/doc/edg/edg_WhatIsMVC.html

Hope that Helps
Cris

"Hope you still working out - I miss Equinox"

Hi Ben,

I wouldn't worry about it to much 'People' say a lot of stuff. The vast majority of people are just muddling through in the best way they can. If you build it in the way that makes it simpler to maintain and easier for other people on your team to understand then surely your doing the right thing.

Theories fine but doing or having done it is better. You can always rejig it later.

Hi Ben,
I read first article of MVC from your blog. Digging deep through the meaning of MVC I found this article which said
... Business logic is the process, formula, algorithm, decision tree, methodology, query, or any other means used to perform a piece of work that is specific to an application...

So I believe that the methodology used to get any relevant information with respect to the request from application is "Business logic"

You can find the full article here - http://www.dougboude.com/blog/1/2008/03/What-IS-Business-Logic-Anyway.cfm

Welcome back, @Ben!

To avoid confounding the topic with software engineering jargon: Business logic constitutes the rules the business wants the software to obey. If you're a contractor/employee, the business is your customer/employer. If you're the boss who commissioned the software to be written, the business is you; you say what the business rules are.

Those who work on the software define application logic as a way to instantiate the business rules. But software environments change and it's possible to define an instance of the business rules for HTML using one kind of application logic, and a completely different instance for XML / web services using completely different application logic.

Like it or not, our industry is subject to trends and fashion. You get something working perfectly, so you want to just let it be. If it ain't broke, don't fix it. But then along comes some new UI, or some new platform, and even though there's nothing wrong with it, you have to rearchitect the whole damn thing to be cool and keep your customers.

Yet all instances have to obey the same business rules.

I wrote and maintain a 15 year old search engine that has really kept up with the times: It allows you to view results tabularly, as a detail report, as a summary report, as csv, as another spreadsheet import format different from csv, for desktop browsers, for mobile devices, as web services, etc. I haven't been asked to generate charts and graphs yet, but you know from some SVG/Canvas code I showed you once (for a different search engine) that that's possible too.

Yet all of these different instantiations of the same search obey the same business rules (sorry that some have to be cryptic):
(1) We can't let searchers retrieve ridiculously large result sets and slow the servers down for everybody else. So insufficient search criteria has to be regarded as an error.
(2) Privacy-protected data is never divulged without https, login and sufficient privilege.
(3) Certain kinds of data are not retrieved unless certain search criteria are entered.
(4) Consistent search behavior. Specifically, adding a new category of search criteria (e.g.: state code) narrows a search, but entering multiple values for that category (e.g.: NY, NJ, CT, MA) broadens it.

All of those business rules derived from what my customer wanted the search engine to be. All instantiations (faces, views) obey those business rules. But only web views provide accessibility enhancements for blind users with screen reading browsers, which implies structuring HTML, JS and CSS in a particular way. That's application logic.

In the long run, to achieve this kind of flexibility, you have to segregate business rules from application rules. Business rules reside nearer to the data. Application rules reside nearer to the user, or the platform/middleware through which you talk to the user.

One last observation and I'll leave you to your holiday shopping:

Stored procedures are a good place for business rules, if that option is available. If all developers have to funnel their updates through stored procedures, the rules will be consistently enforced across all applications. Of course, you have to write the procedures intelligently to avoid inefficiencies, deadlocks, etc, but stored procedures are pretty darned close to the data. If a rule doesn't seem like it belongs in the procedure, if it seems to specific to user interface, it's probably an application rule.

... er, I meant, TOO specific to user interface. Sheesh.

Don'tcha just hate it when you write something long and thoughtful, but your proofreading breaks down in the very last sentence?

Not enough coffee, apparently.

Redundancy's okay.

In one of my banking applications, fixed interest rate loans require initial interest rate but not spread over prime. Variable interest loans require spread over prime, but not initial interest rate.

In the web pages, users have come to expect immediate feedback. Clicking the Fixed radio button results in initial interest rate being marked mandatory and spread over prime being marked optional, in our case, via JS that adds or removes classes. Clicking Variable results in the opposite.

Yeah, that's in the application logic. But that's okay. In fact, accessibility for cognitively disabled users pretty much requires that kind of implications-revealing feedback.

In a web service, you wouldn't have that sort of bleed-over of business logic into application logic. That's okay too.

It's not like rigorously normalizing a database, where you're trying to make sure each data element appears in only one place on the database. A rule doesn't have to reside only in business logic or application logic, never both.

The important thing is, in the absence of upfront application logic, business logic catches and prevents violations of business rules.

My $0.02.

Checkout the 'Service Layer' example for Overview of Application Layers

Pg53 @ Pro Spring MVC w Web Flow ...

Application Layering ...

"Layers should be thought of as conceptual boundaries"

Presentation =

This is most likely to be a web-based solution. The presentation layer should be as thin as
possible. It should also be possible to provide alternative presentation layers like a web
front-end or maybe even a web service façade. This should all operate on a well-designed
service layer.

Service =

The entry point to the actual system containing the business logic. It provides a coarse grained
interface that enables use of the system. This is also the layer that should be the
transactional boundary of the system (and probably security, too). This layer shouldn't
know anything (or as little as possible) about persistence or the view technology used.

Data Access =

An interface-based layer that provides access to the underlying data access technology,
but without exposing it to the upper layers. This layer abstracts the actual persistence
framework (e.g., JDBC, JDO, or JPA). Note that this layer should not contain business
logic.

"Communication between the layers is from top to bottom. The service layer can access the data
access layer, but the data access layer cannot access the service layer. If you see these kinds of circular
dependencies creep into your application, take a few steps back and reconsider your design. Circular
dependencies (or bottom to top dependencies) are almost always a sign of bad design and lead to
increased complexity and a harder-to-maintain application."

http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-servlet

@Ben, handler layer == controller layer in Coldbox.

http://henrylearnstorock.blogspot.ca/

@Ben, handler layer == controller layer in Coldbox.

@Ben, Henry ...

I might suggest taking a look at implementing the Front-Controller MVC design pattern. ColdBox has a mature and feature rich architecture that supports the delegation features your looking for in CF ...

http://wiki.coldbox.org/wiki/ColdBox.cfm#Core_Conventions

I like webmanwalking's notion that business logic implements business rules, and business rules are basically requirements. At implementation time you then get application logic and domain logic, and the business rules could be implemented in either or both depending on the degree of generality desired.

To me domain logic is all about generality. What *is* a thread? What are it's properties, and what can it do? Come up with a definition that you're happy to run with across all the applications of this kind that you might want to write, and that's domain stuff. This is why really rich domain models are rare - because most domains have very few truly general rules - and complicated - because a lot of the rules have be parameterized to make them general.

So if all discussion threads in the universe of applications you might want to write have to be less than three days old to be renamed - that's domain logic. If only this particular application cares about thread age and renaming - that's application logic. If thread age has a bearing on renaming in all applications, but different applications might allow different ages - that's a mix. The "care about thread age when renaming" is domain logic, and "make the threshold three days" is application logic.

@Ben ... 'Hodgepodge of Responsibilities' ...

You may want to research 'ISP' or 'Interface Segregation Principles' - The 'I' in a S.O.L.I.D. application design ...

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

@Ben "The part of this whole process that comes back to bite me is often the gathering of data for display "

I feel your pain ... Systems architecture is complex. In my bootstrap description ... model layer 'data-structures' are transitive and dynamic by nature - handling attributes and behaviors responsible for their effective transport is 'The Rub'

I think we can only hope to make good progress in this area ... as perfection is quite illusive ...

Back again ...

Sorry for all the responses ... Got my attention here ... I'd say @Rick and @WMW's view are accurate ...

In this case ... attempting to define both coarse and fine-grained logic and maintaining a separations of concerns is where JPA / Hibernate really shines By designing interfaces that work with data mappers and repositories ... we can define abstract DTO interfaces for both the UI layer and the DA layer without most of the negative issues associated with coupling and design scale.

I'm just getting my feet wet with full-scale application architecture but the benefits of designing model and views through JPA are huge.

The Spring Data JPA is probably something you'd get some value from too ...

http://static.springsource.org/spring-data/data-jpa/docs/current/reference/html/#repositories.core-concepts

@Ben ...

I've slapped together a spring data jpa demo app that I modified from http://krams915.blogspot.com/ ...

Examples are a lot clearer than discussion sometimes ... :-)

https://github.com/EdwardBeckett/spring-jqgrid-tutorial

Let's say you want to develop a forum application and sell it. This may be redefining "business logic" but you could go about it like this for pragmatic reasons:

"Business logic should be that which consumers of your application can change and application logic is the fixed part. The controller has to mediate between the two."

Business Logic:
Do new users need to click an activation link to validate their email?

Application Logic:
When you click on an activation link unlock the user and allow logins.

Business Logic 2:
When a user logs in x times incorrectly, lock their account.

Application Logic 2:
Call business logic on failed login. If it returns 'L' then lock the account.
Provide unlocking mechanism.

Business Logic would then be that part of the App which can be customized/overwritten and will (somehow) survive an upgrade.

I often take the approach of business logic typically being objects that are unaware of their surroundings.

Example, I create an object, set some properties for it, and call the doYourThing() method and check for output.

It wouldn't know anything about the UI, or how the data itself is gathered, nor what to do with the data, how to store, etc. It just processes the information according to the business rules requirements.

This way, I can manually test the object however I wished using things like test cases and such to verify the business rules are operating correctly.

Afterwards, I start wrapping/extending the object with application and storage specific code, maybe a layer of validation before the data goes in to the core and as it comes out.

This is all decoupled from the core logic and is theoretically interchangeable.

In coldfusion, I typically do this with a cfc, and then create cfc wrappers that instantiate (or directly call from persistent scope) the object. These wrappers would handle remote webservice calls or ExtJS Direct invocations. They take care of validating the webservice call, validating the incoming xml against schemas before the data makes it to the core, building success and error responses, parsing and creating json responses, etc.

Most often with coldfusion code, I leave DB specific code inside the core as I know what system I'm writing for, otherwise, this is where the ORM stuff would come into play inside the core.

I typically have something like:

/Components/Something/widget.cfc
/Webservices/Something/widget.cfc

The latter processes remote calls, validates against messaging schema, build error response if bad input, calls the former, builds response, validates response against messaging schema, returns response.

A little bit different with my ExtJS Direct stack, but similar idea.

For business logic specific to UI, it can be similar.

Your click button press event wouldn't perform much. I like to have them create pointers to the elements I need to check and pass those in to an object. This way, the dom locations or names can change, but the core business logic doesn't need to.

onChange=doThing();

doThing(){
var in1 = document.getElementById('text1');
var in2 = document.getElementById('text2');

var v = new Validator(in1, in2);
v.validate();
if(!v.success)
{
alert(v.errorMessage);
}
}

Im not sure if you are still interested, but I hope this

http://www.justbuildsoftware.com/?p=9

can explain some. A few years back I was trying to become a better programmer too, right around the same time I was asking myself the same kinds of questions.

Cheers

@Sean,

I found your comment to be very concise and has cleared up some confusion on my own projects. Just this morning I asked myself; is my business logic in the correct place, then I asked myself; what is business logic?

According to your comment ive got all the pieces in the places they should be.

My 2 cents.

Application Logic consumable logic. Change aspects, behavior, input, etc.

In a console application, the application logic is the input params and the output response. In a schedule task, it's the same. The trigger that make the application start and the output, both are Application Logic.

Please note, Consumer does NOT have to be a User.

In a webapi, Application Logic refers to request, response, INPUT validation.

Side note: Validation can and happens at multiple levels of an Application. Some at Application Logic and other not!

So now, what is business logic ? Business Logic is the process that happen under the scene, without notifying a consumer, but the application logic and without getting input from the consumer but the application logic.

That's why business logic can have be shared in multiple applications, and applications shared with multiple consumers. business logic cannot be shared by consumers, because are not consumables.

So, WHERE should business logic be ? That's sounds as a good question. and the answer as I see it is very simple: Anywhere that makes sense.
Spa application can have heavy business logic on the client 'layer' while standard web apps have less.

If you want to do heavy business logic on your client side, you can have SQL-like queries in your Javascript. (see breeze.js for example).

In an application like Entity Framework ORM, the lambda expression like .Where() .Select(), etc are all EF application logic. The actual implementation on how that translates that to a query is EF business logic, because the only consumer is the Application Logic while the Application Logic can have many consumers.

Last words:
If a consumer interacts with an application logic, the application logic *may* call the business logic and interpret the response (if any) from the business logic and then the application logic interacts with the consumer again. It doesn't matter if that 'business logic' is a DLL behind 213432 layers, the same in page Javascript or a store procedure in a DB.

TL;DR;
Business Logic is code that has no consumer but Application Logic.
Application Logic is code that has n consumer(s).

Together with my coleages I had this frustration too. A few years ago we were working on a language (XML) that would be able to describe a domain fully and completely to be able to but all business logic into the domain model.

The idea was to generate UI automatically from the domain model and to reduce the code for the controller as much as possible. Martin F"owler's Patterns of Enterprise Architecture" ans Eric Evan's "Domain Driven Design" were our most important inspirations. I also recommend Vaughn Vernon's "Implementing Domain Driven Design" very highly.

Today we are able to do just that. Have a look at http://sclable.com and if you have any questions I am happy to share our ideas!

all the best,
Roland

There is no spoon. I think this question could be paralleled with similar ideological dualistic conundrums such as where do I end and you begin? Everything bleeds into everything. I don't think there is a finite line to be drawn in the sand that will be universally agreed upon that separates the two in a quantifiable way. The useful function of programming paradigms is what is most important in my opinion. Adopting it should help you not frustrate you.

In this case for me it is useful to think about the data sets I will be working with and how they tie into the real world as business logic. For instance a fulfillment center needs to track orders among many things.

There are many operations on orders but when an order changes there are finite things that occur if its line items change in quantity then the corresponding inventory of its product will decrease. There is no application in the fulfillment industry that would say otherwise.

The result of this business logic is useful to different people in different ways. A customer service representative will be most interested in being able to quickly access order details to answer a clients questions. The owner will want to see profit and loss based on inventory and sales. So that to me is application logic. People can say I am wrong but if it helps me code better than that was the purpose of the contemplation of the ideology from the get go. But is someone had a more useful understanding then it would be worth looking back into it.

My main point is how useful is your definition not how authoritative is its speaker in their tone. That and there is no spoon or right answer. I very much appreciate the conversation your humble and honest tone brought. It is especially impressive coming from a CTO.