When you create software, you often hear about “business logic”. It is a very important term, but it is not as simple as it seems. What the term actually means will depend on who you ask. For example, project managers may have a different understanding than developers. But at the same time, it is crucial for the company. Misunderstanding the term can lead to software that doesn’t do what the business actually needs.
Although business logic understanding and interpretation may differ between teams, everyone in a company should have the same understanding of the end goal. So while the understanding and interpretation of the business logic may differ from team to team, you need them to have the same understanding of the end goal. In this article, you will learn what business logic is.
Imagine the following situation. You are browsing an online shopping page. You have an “add to cart” button on each product page. If you click on this button, the product will be added to your basket. But what if you already have this product in your shopping cart and you click “add to cart” again? Should the number of products in the cart increase? Or should you get a pop-up saying “you already have this item in your cart”? Good question. But the better question is, who should decide what happens? Obviously, developers will have to implement one or the other feature. But should a developer make the decision? Of course not; it should be a business analyst decision. And so, the answer to our question is defined by a “business logic”.
Developers should know what the business wants for each case and write the appropriate implementation in code based on that. In other words, developers need to know the “business logic”. Anything that explains how or why something should work is business logic. The developer’s job is to implement this business logic as code.
Another aspect defined by the business logic is the relationship between the different software objects. For example, imagine a online bank. How are accounts, loans, users, and credit cards related to each other? Can a credit card be assigned to a loan? Probably not, it must 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 business logic. From a developer’s perspective, it doesn’t really matter; the code will likely be similar regardless of the relationships. But for the company, the difference is huge.
Let’s go back to our example of an online shopping platform. If you tried to list all the things this platform has to do, that list would probably be quite long. Here are some basic requirements:
- Ability to register users
- The “Forgot Password” feature
- Ability to add a product to a cart
- Continuous stock monitoring (to display “available” or “not available” for each product)
- Sending emails to users (e.g. “order created” or “order shipped”)
- Ability to contact other systems (e.g. create new shipping requests from third-party shipping providers)
- Validation of user-provided data (such as addresses or credit card details)
It’s only a fraction of what a modern shopping platform has to do. Now let’s ask which of these features helps the store earn money? Certainly not all. The “I forgot my password” functionality, for example, is not so important for the company. Sure, it’s necessary and good for the users, but if that’s all the users do, the store 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 just “what this company makes money on”. It’s just another look.
Business logic implementation time
This difference should be considered when planning code changes. For example, imagine you ask the developer, “How long will it take to add a new shipping provider to our store?” The answer to such a question can be tricky. This is because consuming a new API might be trivial, so implementing business logic alone (adding a new shipping provider) might not take a lot of time. But you’ll have to do a lot more than that to make the user experience (UX) transparent: 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 all “business logic” implementations, there are a lot of things to do that are necessary but do not directly contribute to the implementation of the business logic itself.
Do you ask the developers for shipping prices?
Let’s take another example, delivery. From a developer’s perspective, adding shipping to the order is pretty straightforward. They just need to implement code like “add X amount of the order according to the delivery address. But where does X come from? It does not matter. For example, X can be retrieved from a database or Shipping Partner API. What matters is that business logic decides where to pull X from.
It is the company that can dictate, for example, different rates for different postcodes/countries. It is the company that can define which shipping company to use for which countries. Business logic can also determine if tax should be added depending on the country. You can also watch it from the other side. You want your developers to add a limited promotion for certain products in your store. Do you just tell them “please implement the discount”? Of course not! They should know the business logic of this feature. They probably already know how to implement discounts from a code perspective. But they need to know how long the promotion should last, which users should be able to use the promotion, which products should be discounted, etc. All of these questions are answered in business logic.
Developers vs companies
We have established that business logic primarily refers to software functionality that provides 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 because software is getting more and more complicated. And developers have to think about many different aspects and functions of the software for any new feature a company wants to implement. Defining business logic will help developers focus on what really matters. Otherwise, developers can spend a lot of time writing code that doesn’t help the business achieve its goals.
For example, consider error handling. Developers will (well, they should) spend time writing logic for what to do if something goes wrong. Their code can be simple and generic, like “if an error occurs, display a generic error message”. But they can also try to write separate functions for each possible error message. Of course, which method to use will depend on your needs. Either way, they’ll be spending time on something that should be done but doesn’t add new functionality to the code. Therefore, all this work will not be part of the business logic.
As you can see, the business logic is simple and complicated at the same time. It’s relatively easy to understand, but it’s not always clear where it ends. Some tasks may seem important, but they are not strictly necessary for implementing business logic. Here’s a secret: it’s not that important to have business logic Perfectly defined. It is much more important to have a defined business logic at all. And more importantly, to have it explained to the developers as well. It’s called “business logic”, but that doesn’t mean it’s important for businessmen only. It’s actually just as important that your developers know your business logic as your management. Because without a shared understanding of business logic, you might not get what you asked for.
It is also worth mentioning that nowadays software is quite complicated and usually decentralized. Therefore, implementing business logic usually means touching several different parts of your system and modifying more than one API. This creates a risk that one of these changes implement some vulnerabilities. Properly securing multiple APIs is not an easy task. Fortunately, a first step is discover the APIs you use and how they interact with business logic.
Traceable AI can help you observe, map and secure your APIs. It’s really easy to get started, it can automatically scan and detect all your APIs and provide you with valuable insights and risk monitoring. On top of that, Traceable AI also has built-in threat blocking and can even help you pass audits and meet compliance requirements. It is a veritable powerhouse for all your PLC security needs.
If you also want to learn how to implement API governance, check out our article A Beginner’s Guide to API Governance.
This post was written by Daliso Zuze. Daliso is an expert in agile software delivery using Scrum. Besides that, he is an experienced digital transformation consultant and entrepreneur. His technical skills are centered on mobile application development and machine learning.
The post office What is Business Logic? The Curious Reader’s Guide. appeared first on Traceable Application and API Security.
*** This is a syndicated blog from the Security Bloggers Network of Blog written by Daliso Zuze. Read the original post at: https://www.traceable.ai/blog-post/what-is-business-logic