There’s a certain amount of stuff that’s more or less common to all computer programs: the need to get input from and display output to the user, the need to interact with various features of the hardware (e.g. saving data to disc), etc. A lot of the code in the program is infrastructural boilerplate, transforming and moving around data between those things.

“Business logic” is everything else – the code implementing the computation that fulfills the program’s purpose, described in terms of the problem domain.

For example, if you’re “manipulating a string” that’s probably infrastructural code, whereas if you’re “formatting a mailing address” that’s probably business logic.

The common sorts of apps that exist to automate some straightforward bureaucratic workflows (i.e. filling out forms, but on a computer) are often designed with a “three tier” application architecture. The first tier is the UI, the third tier is the database store, and the middle tier is the business logic doing the calculation and validation that a clerk would’ve done by hand in the previous paper-based process.

Apps that operate in a more complicated way, such as CAD software, might tend to have a fuzzier distinction between business logic and infrastructural code.

In software, business logic is the non-technical requirements. For example, users with the “trainer” role can only take on four “trainees” maximum and cannot train each other. Note there was no discussion of code in that example, it was just a requirement of a system that a software developer will have to meet.

It’s the parts of a program’s concepts, rules and behaviours that are specific to the program’s task. For instance

• Items, a shopping cart and the conversion of such a cart into an order at checkout in an e-commerce application.
• Clips of video and audio, static images etc. and the compiling of these into a single output video for a video editor.
• Vertices, triangles, meshes, animation rigs etc. for a 3d editing program.
• Accounting standards and tax laws for an accounting system.

When developing software you deal both with these kinds of specifics and generically reusable concepts that are more purely computational science, so a term to distinguish them is handy.

I think of it as the parts of code that are specific to a business. The unique stuff that the business itself does, not generic stuff that all software does.

Spotify does music, a “play” function that starts music is business logic. A function that calculates the average of a set of numbers is generic code so not business logic.