What IS 'Business Logic', Anyway?
So I'm having a discussion with my friend Jim the other day about an article he was writing and I give him a suggestion regarding one of his sentences on the subject of encapsulation. He had stated that encapsulation is about hiding data, while I appended the fact that it also hides business logic. This prompted an immediate discussion on the term 'business logic', and what exactly it was and was not. So, I thought it good to share my own personal definition of the phrase in order to solicit the input of others to see if the way I think of it differs significantly from the connotation it holds for the community at large. I'm also adding this to my Personal OO Lexicon for posterity's sake.
Business Logic
So this Controller is sitting at the bar babying a Belvedere Gimlet when he gets a call from his Framework asking him to please provide the value for the current user's next inspection date. A bit perturbed but never one to tarry when the Framework makes a request, he immediately dials his peep, Joe Object, down in the Model district and asks for user 1287's next inspection date. Joe Object quickly does his thing and gives Controller the value he requested, who in turn hands it off to his Framework.
The process that Joe Object went through in order to calculate the user's next inspection date is an example of what is referred to as "Business Logic". It's the process, formula, algorithm, decision tree, methodology, query, magic 8 ball, or any other means used to perform a piece of work that is specific to this application. 'Business Logic' is the answer to the question "How did you get that value?". Consider this dialogue: "Hey, Joe Object, how exactly did you come up with that inspection date?" asks Controller. "Since my job is to encapsulate the processes I use, I can't tell you," Joe Object says. "All I CAN say is that I executed the business logic for that particular request and gave the result to you."
As an aside, anything that you the developer would classify as Business Logic (as defined above), is the PERFECT candidate for inclusion in the CFCs that compose your application's MODEL; in fact, I would go so far as to say that it is mandatory that such code reside within your model. The rule I use (which I gleaned from perusing blogs and mailing lists) when deciding if code is business logic or not is this: "If I had to change frameworks tomorrow and the ONLY thing I can take with me is my Model, is this a piece of functionality I would consider to be uniquely associated with this app?"
Business Logic
So this Controller is sitting at the bar babying a Belvedere Gimlet when he gets a call from his Framework asking him to please provide the value for the current user's next inspection date. A bit perturbed but never one to tarry when the Framework makes a request, he immediately dials his peep, Joe Object, down in the Model district and asks for user 1287's next inspection date. Joe Object quickly does his thing and gives Controller the value he requested, who in turn hands it off to his Framework.
The process that Joe Object went through in order to calculate the user's next inspection date is an example of what is referred to as "Business Logic". It's the process, formula, algorithm, decision tree, methodology, query, magic 8 ball, or any other means used to perform a piece of work that is specific to this application. 'Business Logic' is the answer to the question "How did you get that value?". Consider this dialogue: "Hey, Joe Object, how exactly did you come up with that inspection date?" asks Controller. "Since my job is to encapsulate the processes I use, I can't tell you," Joe Object says. "All I CAN say is that I executed the business logic for that particular request and gave the result to you."
As an aside, anything that you the developer would classify as Business Logic (as defined above), is the PERFECT candidate for inclusion in the CFCs that compose your application's MODEL; in fact, I would go so far as to say that it is mandatory that such code reside within your model. The rule I use (which I gleaned from perusing blogs and mailing lists) when deciding if code is business logic or not is this: "If I had to change frameworks tomorrow and the ONLY thing I can take with me is my Model, is this a piece of functionality I would consider to be uniquely associated with this app?"
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: What IS 'Business Logic', Anyway?
Nice Doug. Very simple and concise. I just forwarded this to the rest of my team, some of whom are still wrapping their heads around the OO mindset.
Posted by 'Cutter' Blades on March 6, 2008 at 10:35 PM
Re: What IS 'Business Logic', Anyway?
Great Article. If you had the time could you go over what application logic is. As i always get business and application logic mixed up.
Posted by Charlotte on August 22, 2008 at 8:06 AM
Re: What IS 'Business Logic', Anyway?
Thank for explaining this.
Posted by Sam on November 12, 2008 at 9:05 AM
Re: What IS 'Business Logic', Anyway?
I've been working as an embedded software engineer for 30 years. I started a new job a couple weeks ago and for the first time came across the phrase, "business logic". It's so prevalent in this place that most of the software diagrams say BL all over them. I asked my supervisor what "business logic" was and got the answer the code is divided into "user interface" and "business logic". I'm trying to understand what it really means and that's how I came across your blog.
Your example assumes that Joe Object is performing work related to business. I have rarely written any code that is involved with business practices, my current job is no exception. To me, using "business logic" to describe general code that performs a general algorithm is a misnomer. Charlotte's "application logic" seems a much better general term. It seems to me that "business logic" would be a special case of "application logic" that actually performs some action that is directly related to how a business runs.
Your example assumes that Joe Object is performing work related to business. I have rarely written any code that is involved with business practices, my current job is no exception. To me, using "business logic" to describe general code that performs a general algorithm is a misnomer. Charlotte's "application logic" seems a much better general term. It seems to me that "business logic" would be a special case of "application logic" that actually performs some action that is directly related to how a business runs.
Posted by Tim on January 8, 2009 at 9:29 AM