Business Logic refers to the underlying processes within a program that carry out the operations between a company’s servers and the user interface with which that company's customers interact. Business logic is more properly thought of as the code that defines the database schema and the processes to be run, and contains the specific calculations or commands needed to carry out those processes. The user interface is what the customer sees and interacts with, while the business logic works behind the UI to carry out actions based on the inputted values.
Business Logic vs Business Rules
Business logic is often mistaken for something that encapsulates the business rules implemented in a system. There is an important difference between the two. Business rules are a formal expression of business policy, while business logic determines how this policy is implemented as a process. For example, the application of VAT on invoices is a business rule but the calculations involved in applying it are implemented as business logic. The catch is that the separation between business logic and other parts of the system is not necessarily that clear. Many business rules need to be implemented across more than one tier. For example, a business rule that dictates that negative figures should always be presented on financial reports affects both data processing and report writing, i.e. presentation and business logic. This is one of the drawbacks of tiered or layered architectures that seek to isolate business logic into a separate tier. It can be difficult to meaningfully segregate functionality into a self-contained tier depending on the type of processing that is being carried out. Over the long term this “business logic” often leaks across tier boundaries so the implementation of business rules becomes scattered across a system. This gives rise to anti-patterns such as “shotgun surgery” where any change in a business rule requires numerous changes in different parts of the system.