The term "business logic" doesn't make sense... not without the non-business logic part!
When you write code, the parts of the code that can genrealize to solve problems of any other business are the parts that are not business logic. So when someone says to "separate business logic", they're basically saying the opposite - separate the generalizeable parts of the application from the requirements stemming from the business.
Example:
Lets say you write code to display an altitude chart of a bicycle trip recorded with a GPS device. For every coordinate, there is the altitude included. The specifications say to use a white gradient if the altutude is above 2000m, brown if its above 1000, green below 1000.
You could implement this as a drawAltitudeChart(coordinatesWithAltitude) which would draw the axes and the line with the right gradient colors. But then, your business logic is all mixed up with your drawing logic, and you can't use this function to draw anything else. What if someone wants to draw a speed chart later? You can't reuse the code.
However, if the implementation is
drawChart([[x, y], [x, y], ...], {gradient: {y: 0, color: 'green'}, y: 1000, color: 'brown'}, {y: 2000, color: white})
Then you could have your "business logic" calculate the distance from the GPS coordinates as well as the altitude at each distance point, then pass the gradient and those points to drawChart.
It could also calculate distance and velocity, and pass that to drawChart (probably with the gradient parameter set to null, and with a lineColor parameter instead).
Therefore the answer is: the business logic are the parts the business cares about. The business cares about drawing an altitude chart from GPS points. The business doesn't care about the details on how the lines are drawn on a (say) HTML5 canvas element, or how gradients are shaded etc. We want to separate that part, or use a ready-made generic library if possible.
The reason why the term is so unclear initially is that one only gets a sense of what business logic is once they've implemented several similar business requirements, possibly even over several different businesses; seeing parts that are the same, then generalizing common segments of that code to a library of functions or classes shared between all those parts. (e.g. a chart drawing library)
This also works in the reverse! You could make a different renderer for an altitude chart - say, a game-like 3d animation of a bicycle that simulates hill climbing and downhill driving. The business logic part calculating the distances and velocity still stays the same, but there is now also a 3d journey simulator library. You could write it to always show a bicycle 3d model - or you could make the model configurable, therefore generalizing beyond the business of a cycling GPS app. Does that make sense? Maybe - you could use that simulator in a different app that lets you plot a car trip then simulate a timelapse preview of the journey.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The term "business logic" doesn't make sense... not without the non-business logic part!
When you write code, the parts of the code that can genrealize to solve problems of any other business are the parts that are not business logic. So when someone says to "separate business logic", they're basically saying the opposite - separate the generalizeable parts of the application from the requirements stemming from the business.
Example:
Lets say you write code to display an altitude chart of a bicycle trip recorded with a GPS device. For every coordinate, there is the altitude included. The specifications say to use a white gradient if the altutude is above 2000m, brown if its above 1000, green below 1000.
You could implement this as a drawAltitudeChart(coordinatesWithAltitude) which would draw the axes and the line with the right gradient colors. But then, your business logic is all mixed up with your drawing logic, and you can't use this function to draw anything else. What if someone wants to draw a speed chart later? You can't reuse the code.
However, if the implementation is
drawChart([[x, y], [x, y], ...], {gradient: {y: 0, color: 'green'}, y: 1000, color: 'brown'}, {y: 2000, color: white})
Then you could have your "business logic" calculate the distance from the GPS coordinates as well as the altitude at each distance point, then pass the gradient and those points to drawChart.
It could also calculate distance and velocity, and pass that to drawChart (probably with the gradient parameter set to null, and with a lineColor parameter instead).
Therefore the answer is: the business logic are the parts the business cares about. The business cares about drawing an altitude chart from GPS points. The business doesn't care about the details on how the lines are drawn on a (say) HTML5 canvas element, or how gradients are shaded etc. We want to separate that part, or use a ready-made generic library if possible.
The reason why the term is so unclear initially is that one only gets a sense of what business logic is once they've implemented several similar business requirements, possibly even over several different businesses; seeing parts that are the same, then generalizing common segments of that code to a library of functions or classes shared between all those parts. (e.g. a chart drawing library)
This also works in the reverse! You could make a different renderer for an altitude chart - say, a game-like 3d animation of a bicycle that simulates hill climbing and downhill driving. The business logic part calculating the distances and velocity still stays the same, but there is now also a 3d journey simulator library. You could write it to always show a bicycle 3d model - or you could make the model configurable, therefore generalizing beyond the business of a cycling GPS app. Does that make sense? Maybe - you could use that simulator in a different app that lets you plot a car trip then simulate a timelapse preview of the journey.