I have a hard time understanding what business logic is compared to other logic in a codebase. Can someone explain it to me?
I have a hard time understanding what business logic is compared to other logic in a codebase. Can someone explain it to me?
For further actions, you may consider blocking this person and/or reporting abuse
I write lots of business logic so I feel kinda qualified to have an opinion here. I’m excited!
There is the normal control flow logic - if/else’s, while loops and for loops. There’s the logic that glues together a program - event handlers, state management, etc.
Then there is business logic. It’s the rules your users make up. In my case, my users are fisheries managers, so business logic is like: if this landing of fish puts them over their quota limit, lock their account and notify the ticket writing department. Or a person in program A may transfer quota to some else in program A, but not someone in program B unless they have a valid medical transfer certificate.
Business logic is the weird flows and rules that only make sense in the context of the user’s business
It's easier to understand if you try to classify your code in two categories:
business logicandinfrastructure logic.Business logic, as other people commented, is the logic that is defined by the business.
Infrastructure logic is the logic that makes your app work.
Ideally, you want to separate both logics as much as possible.
Some classes should ideally read like "if the customer buys 2 products or more, apply discount. If not, don't apply discount".
Others will read like "if the HTTP response from the remote API is not 201, wait x seconds and retry".
One code defines what your users want the application to do. The other code is needed to make your program work.
Obviously, the line sometimes is a bit blury, but you get the idea.
This is the clearest example for me. Thanks for explaining it like this.
The term refers to those rules, that are defined buy business and that should be implemented within an application.
For example: Imagine that you have an online store where you want to sell all of your products.
You could expect the items to be organized by categories. Maybe you want to show the cheapest first, or the most frequently purchased. Maybe you want to have some featured products, but only during the black Friday.
You might want to sell candy bars at a specific price, and maybe limit that offer to one candy bar per customer.
All those rules are what we call business logic.
It’s just a fancy way to say application logic. The business logic covers the logic that matters to the users or stakeholders of a system.
For example, if you’re building a tax preparation app, all of the various rules around what information people need to fill in and how that gets submitted to the government constitute the business logic.
Since few people really want to pay taxes, in this case the business logic is largely driven not so much by the end-user, but rather by the government to which the software ultimately submits the tax information. I suppose one could say the government is also a user of the tax software in a sense, but I prefer to use the term "stakeholder" to make the distinction from an end-user a bit more clear.
Suppose you're writing a podcast library app. The logic that says, "Put the newest episodes at the top of the list," is an example of business logic - it's something a product owner would care about. It's something that affects the user experience directly. It's something that could distinguish your podcast app from competitors, who might list the most popular episodes at the top of the screen.
By contrast, logic that specifies how podcast files are read from disk is not business logic - your customers don't care, your product owner doesn't care, it's not a feature listed on the app store.
Imagine all logic you could technically write. The business logic is now that part of all logic that is needed for your use-cases.
A front-end example: You can create a slider that slides through hundreds of images for your home-page, but the use-case states that you only should slide through 3 and then start again from the first one, so your business logic restricts your software from doing "all thats possible" to a sub-set of actions.
A back-end example: You can create user records where multiple users have the same email address, but the use-case states that the email address should be unique for every user, so your business logic restricts the creation of multiple users with the same email address.
Business logic is what transforms data/information to (business) value.
Yes, it does not make it much more clear. The key element is in the word transforms. This is what is meant by business logic. It transforms X to Y.
Retrieving data from a database is not business logic. Transforming that data to a view is business logic. Transforming that data to other data is business logic.
How the transformation is performed is the business value of the software. This is where a lot of companies bank their value on. In reality the real value of software is enabling configurable definition of these transformations. The business logic will change over time, as the transformation conditions and rules change over time. If these changes can be accepted in the software via configuration, you are adding true value to the business.
Business value is equally ill defined. It could be anything to reducing cost, to getting visibility to spent cost (in order to reduce cost). In the end, maximize profitability. Maximizing profitability is often confused by maximizing profits. Profit is revenue minus cost. Profitability is the degree in which you can achieve profits. People who spend less time dealing with tasks which can be automated, can spend more time on tasks which cannot. These non-automated tasks do not affect your profits, but do affect your profitability. You should read this as: more attention to conflicts with customers -> happier customers.
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.
Business rules are set and defined by the stakeholders and sit on top of the rules defined by the tech and structre of the application.
For example and app might store customer data; id, name, and phone. The app and db only need to enforce the rule that id is provided and unique. The name and phone would be string data but no requirements are needed for the content. These are rules defined by the application and must be adhered to for it function properly.
The stakeholders (business) however, may require the name to be unique, and a min length. The phone can be blank but if provided must include the area code plus 7 characters and must be all numbers. These are rules defined by the business to meet their needs.
The app would function without the business rules but wouldn't be very useful.
You have different types logic within a framework. Typically logic that applies only to the business you are developing for is what we call "Business Logic". Typically it means taking data from one format, and changing it to another format to present.
A business user want to see the data from a database different than it exists in a database. The logic to make it look different for that business user is called business logic.
I think that the underlying concept behind business logic is “ separate what is important from what is not “
Something like:
If you mix pagination logic with listing customer you end up with code that is hard to maintain, and it is rigid, changing pagination will affect the listing.
It would be better if you define a piece of code that takes care of listing customer data and another that paginate a list of objects.
So following this separation of concerns idea you can apply it to state:
Separate all what describes the business (interactions between stakeholders and your system) from the rest of your code.
When a business rule change you don’t need to scan 100k lines of code to know what needs to change because you separated these rules you know where to find them, they are not duplicated in many parts of your system, so you only need to change one place.
Also business rules change often, so business logic should be easy to change. We can get that benefit by programming based on a set of small objects with single responsibility. ( business objects or domain objects)
Usually these objects arise from refactoring existing code in the search for recognizing underlying abstractions.
This idea sounds pretty cool but unfortunately based on my experience software developers do not invest time to recognize and separate the business logic, we just write code inside some part of the framework and we end up with a mess.
I know that lots of programmers share this question, so thanks for asking.
Hope this help!
All code that says something about your business - is your business logic. Everything else is an infrastructural detal. Say your domain is making donuts. All classes, methods and variables that say “dough” “milk” “filling” “oven” “bake” are your business logic. Everything that says “rest controller” “rabbit mq consumer” “event listener” is infrastrucutal detail.
On a side note, separating two is quite a challenge. Infra depends on business logic but never vice versa. There is no place for frameworks in BL layer, and only few helper libraries like uuid and assertions could be used.
I would recommend Robert Martin’s talks on clean architecture to get an idea of possible implementation of such separation
same problem here, i was assigned to do the backend of the web-app i was staring at this desing and was wondering how to do the business logic for the app or at least just write down the main logic to the paper until i go coding and then follow a tree or like start from the beginning of the whole website architecture
figma.com/file/Z0fxMzNVV67e57cnrSy...
this is the design , how to do the business logic for this for instance what should i put in mind or how to speak to myself in order to retrieve the business logic of this
if that wasn't possible to do , then how can i figure out the business logic , i have a simple superficial of the whole app i made something to define entities in it and i thought if there was a similar thing i can do to figure out the business logic.
All the stuff you'd like to have in a specification in order to be able to redesign / rewrite the code from scratch.
Perhaps overly simplistic?