What is Business Logic?

Business: Commercial enterprise: the activity of providing goods and or services involving financial, commercial and or industrial aspects

Logic: The principles that guide reasoning within a given field or situation

Business logic code is the code that applies the principles that guide reasoning within the business. Sounds fancy, but in fact it is just the code that makes decisions, answers questions, and applies rules. One might argue that in the common business application the business logic code is the most important code. The code you cannot write unless you understand the business and as such is often defined by experts in the field.

What is not business logic code?

In short: all the other code.  Often the common business application also requires code to handle user interaction via graphical user interface components.  There is often code for database access, code for capturing process algorithms, code for handling security, code for logging interaction or auditing events, code for managing errors, code for wrapping external services or components, etc.  These subsystems are all required to complete the application, but are often not directly tied to the business itself.  As mentioned above, business logic is defined by a subject matter expert from the business the application is being built for, however the developer or other related technical authority is often the subject matter expert for this other code.

This is so clear, could you please add some confusion?

Yes. The subsystems noted above (data access, user interface code, etc.) also have principles that guide the reasoning related to them. So although these subsystems are not tied directly to the business at hand, they do have their own business to attend to and so the logic involved is also technically business logic. This is important for the object-oriented developer since the objects created to handle these subsystems should also be responsible for their own related business which of course is not the business of the application. This is worth noting because often object-oriented developers drop their respected OO principles when working in these other subsystems outside of what they would consider business logic. I did just that until it dawned on me that I was missing all the benefits of an OO design outside of business code.

Why is it important to identify business logic?

• Business changes frequently and we have to know where to look, what to change, and how to easily test our changes
• When discussing the logic with subject matter experts after it has been implemented, we need that logic isolated and at the right level of abstraction without peripheral distractions to minimize logic-to-code translation
• So the business logic code can be kept separate from other code to make sure changing either has little to no effect on the other. Rude developers have a habit of spreading business logic all over an application from the user interface through stored procedures
• We have to be sure not to duplicate business logic so when it needs to change (as it is highly prone to do) we make sure the logic is changed and fixed for all code dependent on that logic
• Business logic is often tied back to requirements to make sure features are implemented correctly

What I might point out is that it might still be wise of us to track the difference between these two types of business logic. For what is often the case is that one tends to be an add-on to the other.

Imagine a system that manages insurance details for customers. The business logic relating to the business of insurance may exists along with business logic that deals with the business of security along with some auditing requirements. Understanding these separate needs, these separate businesses is necessary in order to keep concerns separated and allow for objects that have just one reason to change (SRP: Single Responsibility Principle) of SOLID design principles . In an ideal design the object that has business logic related to insurance would not also contain logic that has to do with security and or auditing. We should be able to make changes to our security model (or swap it out entirely) without breaking our business code.