Dawid Ziolkowski
When you build software, you’ll often hear about “business logic.” It’s a very important term, but it’s not as straightforward as it may seem. What the term actually means will differ depending on who you ask. For example, project managers might have a different understanding of it from developers. But at the same time, it’s crucial for the business. A mismatched understanding of the term can lead to software that doesn’t do what the business actually needs.
Even though business logic understanding and interpretation can differ between teams, everyone at a business must have the same understanding of the end goal. So, even though business logic understanding and interpretation can differ between teams, you need them to have the same understanding of the end goal. In this post, you’ll learn what business logic is.
Business Logic
Imagine the following situation. You are browsing on an online shopping page. You have an “add to basket” button on each product page. If you click that button, the product will be added to your basket. But what should happen if you already have that product in your basket and you click “add to basket” again? Should the number of products in the basket increase? Or should you get a pop-up saying “you already have that item in your basket”? Good question. But the better question is, who should decide what will happen? Obviously, the developers will need to implement either of the functionalities. But is it a developer who should make the decision? Of course not; it should be a business analyst decision. And therefore, the answer to our question is defined by a “business logic.”
Developers should know what the business wants for each case and write appropriate implementation in the code based on that. In other words, developers should know the “business’s logic.” Everything that explains how or why something should work is business logic. The developers’ job is to implement that business logic as a code.
Business Objects
Another aspect defined by business logic is the relationship between different objects in the software. For example, imagine an online bank. How do accounts, loans, users, and credit cards relate to each other? Can a credit card be assigned to a loan? Probably not—it should be assigned to a user. Can an account exist without a user? Maybe it can, maybe it shouldn’t. All of these decisions can be made by looking at the business logic. From a developer’s perspective, it doesn’t really matter; the code will probably be similar regardless of the relationships. But for the business, the difference is huge.
The Software
Let’s go back to our example online shopping platform. If you tried to list all the things this platform needs to do, that list would probably be quite long. Here are some basic requirements:
- Ability to register users
- The “forgot my password” functionality
- Ability to add a product to a basket
- Continuous monitoring of stock (in order to show “available” or “not available” for each product)
- Sending emails to users (for example, “order created” or “order shipped”)
- Ability to contact other systems (for example, creating new shipping requests from third-party shipping providers)
- Validation of user-provided data (like addresses or credit card details)
This is just a fraction of what a modern shopping platform needs to do. Now let’s ask, which of these functionalities helps the shop earn money? Surely not all of them. The “forgot my password” functionality, for example, isn’t all that important for the business. Sure, it’s necessary and good for users, but if that’s all that users are doing, the shop will go bankrupt. The “business logic” in this case is what the business actually cares about. But don’t get me wrong, business logic isn’t simply “what that business earns money on.” It’s just another look at it.
Business Logic Implementation Time
That difference needs to be taken into account when planning changes in the code. For example, imagine asking the developer, “How long will it take to add a new shipping provider to our shop?” The answer to such a question can be tricky. This is because consuming a new API can be trivial, so implementing the business logic only (adding a new shipping provider) might not take much time at all. But you’ll need to do much more than that to make the user experience (UX) seamless: testing, documentation, more testing, maybe some changes to other parts of the system, adding new shipping provider logos to the website, possibly adding new shipping rates to your database, and more. For almost any “business logic” implementation, there are plenty of things to do that are necessary but don’t directly contribute to the business logic implementation itself.
Do You Ask Developers for Shipping Prices?
Take another example, the shipping. From a developer’s perspective, adding shipping costs to the order is quite straightforward. They just need to implement code like “add X amount to the order based on the shipping address.” But where does X come from? It actually doesn’t matter. For example, X can be fetched from a database or shipping partner’s API. What matters is that it’s business logic that decides where to pull X from.
It’s the business that may dictate, for example, different rates for different postcodes/countries. It’s the business that may define which shipping company to use for which countries. Business logic may also determine if some tax should be added based on the country. You can also look at it from the other side. You want your developers to add a limited promotion for some products to your shop. Do you just tell them “please implement discount”? Of course not! They need to know the business logic for that functionality. They probably already know how to implement discounts from the code perspective. But they need to know things like how long the promotion should run, which users should be able to use the promotion, which products should be discounted, and more. All of these questions are answered by business logic.
Developers vs. Business
We established that business logic refers mainly to the functionality of the software that brings business value. But that’s not the end of the story. The term “business logic” has a broad meaning. One of the reasons this term exists is that software is becoming more and more complicated. And developers need to think about a lot of different aspects and functions of the software for any new functionality that a business wants to implement. Defining the business logic will help devs focus on what actually matters. Otherwise, developers may spend a lot of time writing code that doesn’t help the business reach its goals.
For example, consider error handling. Developers will (well, they should) spend some time writing logic for what to do if something goes wrong. Their code might be simple and generic, like “if any error occurs, show a generic error message.” But they can also try to write separate functions for each possible error message. Of course, which method they should use will depend on your needs. In both cases, they’ll be spending time on something that should be done but doesn’t bring new functionality to the code. Therefore, all of this work won’t be a part of business logic.
Summary
As you can see, business logic is easy and complicated at the same time. It’s relatively easy to understand, but it’s not always crystal clear where it ends. Some tasks may seem important, but they are not strictly necessary for business-related logic implementation. Here’s a secret: It’s not that important to have business logic perfectly defined. It’s far more critical to have business logic defined at all. And even more importantly, to have it explained to developers, too. It’s called “business logic,” but it doesn’t mean it’s important for business people only. It’s actually equally important that your developers know your business logic than your management. Because without a shared understanding of business logic, you may not get what you asked for.
What’s also worth mentioning is that nowadays, software is quite complicated and usually decentralized. Therefore, implementing business logic usually means touching quite a few different parts of your system and changing more than one API. This creates a risk that one of these changes will implement some vulnerabilities. Properly securing multiple APIs is not an easy task. Fortunately, a first step is discovery of the APIs you use and how they interact with the business logic.
Traceable AI can help you observe, map and secure your APIs. It’s really easy to start with, it can automatically scan and detect all your APIs and provide you with valuable insights and risk monitoring. On top of that Traceable AI has also built-in threat blocking and can even help you pass audits and fulfil compliance requirements. It’s a real powerhouse for all your API security needs.
If you want to also learn how to implement API governance, check our post A Beginner’s Guide to API Governance.
This post was written by Dawid Ziolkowski. Dawid has 10 years of experience as a Network/System Engineer at the beginning, DevOps in between, Cloud Native Engineer recently. He’s worked for an IT outsourcing company, a research institute, telco, a hosting company, and a consultancy company, so he’s gathered a lot of knowledge from different perspectives. Nowadays he’s helping companies move to cloud and/or redesign their infrastructure for a more Cloud Native approach.
