I've heard people talk about business logic a lot at work, and online, and I've read several questions on this site about it, but the term still doesn't make a lot of sense to me. For example, here are some (paraphrased) statements I often see:
"The business logic is the part of your program that encodes the actual business rules." Most of the definitions I've read are circular ones like this.
"Business logic is everything unique to your particular application." I don't see how this is different from "your particular application is nothing but business logic", unless we accidentally reinvented a bunch of wheels we could have used existing 3rd party software for. Hence the question title.
"There should be a Business Logic Layer above your Data Access Layer and below your GUI Layer." In the code I write, the database accessors have to know what data they're supposed to be accessing, and the UI code has to know a lot about what it's displaying in order to display it correctly, and there's nothing to really do in between those two places other than passing blobs of data between client and server. So what's actually supposed to go into a Business Logic Layer?
"Business logic should be separate from presentation logic." Most of the feature requests we get are to change the presentation logic for business reasons. If one of the business rules is to display US government bond prices in 32nds notation by default (while also providing a UI for the user to configure that), the presentation logic needs to at least know this rule exists, if not fully implement it. Also, it seems like a major part of UX design is helping the user understand the business rules our software is trying to implement.
Is it possible that I actually am on a team that only does business logic, and all the non-business logic is being done by other teams? Or is the whole concept of "business logic" as a separate entity only workable for certain applications or architectures?
To help make the answers concrete: Pretend you have to reimplement the Domino's Pizza app. What is the business logic, and what is the non-business logic of that app? And how would it be possible to put that pizza-ordering business logic in its own "layer" of code, without most of the pizza information bleeding into the data access and presentation layers?
Update: I've come to the conclusion that my team is probably doing 90% UI code and most--but not all--of what you'd call business logic comes from other teams or companies. Basically, our application is for monitoring financial data, and almost all of the features are ways for the user to customize what data they see and how they see it. There is no buying or selling going on (though we integrate a bit with other apps from our company that do that), and the actual data is supplied by loads of external sources. But we do allow users to do things like send copies of their "monitors" to other users, so the details of how we handle that probably qualify as business logic. There actually is a mobile app that currently talks to some of our backend code, and I know exactly what portion of our frontend code I would like it to share with our UI in an ideal world (basically the M in our quasi-MVC) so I'm guessing that's the BLL for us.
I'm accepting user61852's answer since it gave me a much more concrete understanding of what "business logic" does and doesn't refer to.