What is NOT business logic?

Do a Google search for "what is business logic," and you will come up with thousands of answers. In this case, I asked myself the negative question to provide a clearer understanding.

Preface

I asked ChatGPT: In software engineering, what is NOT business logic?

Business logic refers to the rules, calculations, and processes that handle the exchange of information between a database and a user interface. Anything that is essential to the core operations
of an application would fall under the category of business logic.

Things that are NOT considered business logic include:

1. Presentation Logic: This concerns the layout and style of the user interface, such as HTML, CSS, or how data is displayed to the user.
2. Data Access Logic: This includes the code responsible for accessing and managing the data in the database. It handles the actual SQL queries or the use of an ORM to interact with the database.
3. Infrastructure Logic: This covers aspects like logging, error handling, security, and configuration. It's essential for the application to run but isn't directly concerned with the specific business rules of the application.
4. Validation Logic: While some validation can be part of business rules, simple input validations like checking if a field is empty or if an email is in a correct format are usually not considered part of the core business logic.
5. Integration Logic: Code that handles the integration with other systems, like third-party APIs or services.

By focusing on what is essential to the core operations of the application and isolating other concerns, maintaining and scaling an application becomes more straightforward.

Analysis

1. Presentation Logic: It doesn't matter how we display the product on the website. We can show the product with a transparent background, dark-blue letters, aligned to the left, or maybe something entirely different. The business logic is not affected.

2. Data Access Logic: This is tricky, but queries are also not considered business logic. Queries, like presentation logic, are subject to change in any form (think of reports), but the core logic is unaltered. And what about writing? ORMs should just perform CRUD; any other pre-validation must be handled elsewhere (the business logic layer, Root Aggregate, etc.). And stored procedures? That depends on how you treat your stored procedures. You certainly can put business logic there, but I wouldn't recommend it (this is an interesting discussion, but out of the scope of this article).

3. Infrastructure Logic: Configuration, logging, and security are things we might agree are not business logic. Error handling in this context means a failed network call, an inability to access a database, a divide-by-zero error, or other run-time errors.

4. Validation Logic: Sometimes this is the root of much confusion which arises when we establish an actual business rule that is very similar to input validation. Checking that "the phone number must be valid" rule is completely different from "Only accept registrations from users whose phone number belongs to Latin America," which is likely tied to the core operations or strategies of the business. While it is a form of validation (check if it begins with +5x), it's not just a simple input check, like making sure a field isn't empty or a phone number is in a correct format. It's enforcing a business rule that is specific to the requirements of the application or the organization's business model. Therefore, it's aligned more with the business logic than simple validation logic.

5. Integration Logic: This is really simple. The code that handles the uploading/downloading of files to/from AWS S3 should be agnostic to the business logic.

Afterthought

I believe that most of the confusion comes when developers mix up Business Logic with Data Access Logic and Validation Logic, especially on green-field projects that start relatively simple with a couple of entities, straightforward CRUD operations, and REST endpoints, ending up with an anemic domain model [1] [2]. At the beginning, there's hardly any business logic, but once it becomes more and more complex, the problems arise and the code that holds the business logic is spread anywhere, thus considering anything "business logic".

While an anemic domain is not bad for simple projects, it should be treated carefully; otherwise, the business logic will be placed anywhere. If the system is going to be complex, then prefer the rich domain model [3] [4]. You won't question where the busines logic is 🙂.

In other cases, I've seen mixing up Business Logic with Integration Logic. Hexagonal [5] and Clean architecture [6] are good antidotes for that.

Finally, if you blend Business Logic with Infrastructure Logic or Presentation Logic, may the gods have mercy on your soul.