It's Business (Logic) Time

(Sea Dragon Pirate Cruise - Panama City Beach)

If you've worked at a company where your job is to deal with software code, you've most certainly heard the term "business logic".   Recently I had a conversation with my team at Frame.io, and it was clear that we all had different interpretations of what this lingo actually meant.  

I figured each person's experience around the use of the term business logic must color their definition of the term.  Rather than dig up a bunch of blog posts that try to explain as an authority what business logic actually means, I decided to go to the people.  I created a simple google form for people to submit their interpretation of the term, and their role at the company.  I was interested to see if the term had different meanings for different roles.  For example, do quality assurance analysts define the term the same as a product manager?  What about a developer, or manager?

Before I color your interpretation of the term, fill out the form yourself!

The responses had many different takes on the term, some technical, some conceptual, and some glib.  I'll break down the responses first by technical vs conceptual.

Technical

"Calculations and logic that are defined by the business to be incorporated into an application. Not logic that controls standard application functionality."

"Business/Product-critical computation and logic based on dynamic data, like permission sets or billing calculations"

"Code that performs valuable work for a user, that would have needed to be done by a human if this wasn't automated."

"Logic that enforces constraints that are defined by business/product but not required by the underlying technology. For example, limiting the number of users of an account to 25 users. The underlying tech wouldn't care about number 25 except for the fact the business/product has defined it as significant."

"Code pertaining strictly to the business rules, having little or nothing to do with software architecture or the process. Typically able to easily unit test these rules"

"Code that enforces rules needed perform CRUD operations on data in service of product goals and requirements. *Sometimes* separated from actual querying logic and lower level db constraints (but not always). *Usually* separated from rendering (or display) logic, especially when considering a presentational layer such as a web browser (or modern FE frameworks that contain business logic and presentation layers within the same application)."

Conceptual

"Domain specific things that are only relevant to my company and app."

"High-level but defined abstraction layer for rules and limitation of what needs to be implemented in spec or code of, for instance, an API or given ruleset."

"Any custom decision-based logic that isn't a standard algorithm"

"The specific logic that applier to how a program is different from other applications."

Gray Area

"Any function of code operating on the domain that drives business value."

"The part of the code that produces the value the customer wants."

"functionally-pure, independent functions"

Glib

"bureaucratic bullshit"

"business logic, sounds like an oxymoron"

???

"An office building or a room where I have to behave"

"The complex machine which utilizes 1+ simple machines to do a job"

Conclusions

Be careful with the jargon you use, especially when you start on a new team.   The term "Business Logic" most likely has a specific meaning to each team, or organization.  New teams, with lots of new hires may have conflicting definitions, even if they think they are all saying the same thing. If you are new to a team and hear this term being used, don't assume you know what it means to the team.   Even more importantly, if you think your definition conflicts with the team's definition, don't assume they are wrong, and you are right.  It's a flexible term, and the best thing you can do for the team is to have a shared understanding, even if it differs from your previous experiences.