A Simple Way Of Identifying Business Logic

Business Logic

Business Logic is the beating heart of every software system. Yet, many software developers need help identifying it. If we collectively want to build (and maintain!) programs that are easy to work with, we need to get good at this one task. And I have an excellent trick to help you confidently point out the critical logic of any business workflow.

Let’s look at an example.

A New Feature

Imagine you have received the following requirements for a new customer registration process:

Requirement: Register New Customer

Overview:

New customers should be able to securely register themselves on our system using our mobile and web apps via a new RESTful Web API.

Detailed steps:

HTTP POST the customer information to the OAuth2-secured API endpoint /customers.
Validate the received customer information. In particular, check that required fields like first name, last name and email address were supplied.
If the customer already exists (by email address) in the SQL Server database, it’s an error. Return HTTP status code ‘409 - Conflict‘.
Otherwise, save the customer with a unique identifier to the database.
After successful registration, send the customer a welcome email message.
Return the customer, including the unique identifier, to the mobile or web clients with HTTP status code ‘201 - Created‘.

OK, that makes sense and seems reasonable, although it looks like the architect has weighed in with technology specifics.

Now, you remember that it’s a good idea to start writing the business logic before composing other system parts. The reason for this, you recall, is that in the most flexible, easy-to-change systems, the business logic stands independent of technology-specific mechanisms.

Fine, you can get on board with that idea.

But which parts of the requirement are business logic?

Time to change the perspective.

A Paper-Based Procedure

What would this business process have looked like, say, 50 or 100 years ago?

Well, it would have been a manual procedure—most likely face-to-face or by snail mail, but undoubtedly paper-based. It would have run along these lines:

The prospective customer fills out a paper registration form,
The customer hands the form to the assistant (or business owner) for review,
The assistant verifies that the customer has filled out the form completely and correctly. Otherwise, it’s returned to the customer to resolve errors and omissions.
Subsequently, the assistant checks whether the person is already a customer by searching for them in the customer records filing cabinet.
If the customer already exists, the registration stops—no point in creating a duplicate customer record. Naturally, the assistant informs the person that they are already a registered customer.
If the assistant fails to find the customer among the customer records, they write a unique customer number into the ‘Office Use Only’ Customer Number box.
The assistant files the new customer record in the filing cabinet.
Finally, the assistant informs the customer that they are now registered and that they may purchase goods and services.
Done!

Did you find the exercise of visualising the paper-based business process helpful in identifying the underlying business logic within the software-automated workflow? No?

Business logic describes WHAT happens rather than HOW it happens.

Both computer and paper processes try to achieve the same end—the same WHAT—but they do so by different means—or HOWs.

What’s In Common?

Since the business logic is the same in both processes, i.e. registering a customer, we can filter it out from our original requirements by identifying the commonalities of the paper- and computer-based workflows (in bold):

Detailed steps:

HTTP POST the customer information to the OAuth2-secured API endpoint /customers.
Validate the received customer information. In particular, check that required fields like first name, last name and email address have been supplied.
If the customer already exists (by email address) in the SQL Server database, it’s an error. Return HTTP status code ‘409 – Conflict’.
Otherwise, save the customer with a unique identifier to the database.
After successful registration, send the customer a welcome email message.
Return the customer, including the unique identifier, to the mobile or web clients with HTTP status code ‘201 – Created’.

Notice how all the HTTP details drop away. HTTP and web are particular delivery mechanisms and not part of business logic. Does registering a customer have to be done via HTTP? No, of course not. We could instead have chosen a different delivery mechanism, a Windows Service or a console application, perhaps. The HTTP details are relevant to the overall system but irrelevant to the business logic component of that system.

The validation of incoming customer registration data is business logic since that also happens in the paper process—although checking for the presence of a valid email address was rare 100 years ago. :D

That the database will specifically be SQL Server does not concern business logic. Yes, there must be a mechanism to save customer data, but how this we achieve is not a business logic responsibility.

For example, we may want to save and retrieve customer information from other mechanisms, like files, remote services, or persistent queues. Within the description of our business logic workflow, we can use an abstract technology-agnostic term like ‘repository’ to refer to data persistence technologies.

When the customer registration has succeeded, we send the customer a welcome message. Critically, it’s not a welcome email message. Why? Because email is a mechanism. Sure, we will send a welcome notification, but it may not be an email—It could be an SMS/TXT message, an in-app notification, a Slack or Discord message, and so on.

Not A Business Process

At times, an exact version of the process to be created in software may not have existed 100 years ago as a paper-based procedure, say, playing a computer game. However, people did play games back then, like chess, checkers or tiddlywinks. So an analogue exists here too, which we can use to map out the business logic for the computer game.

Conclusion

Whenever you need clarification on which aspects of a technology-laden requirements specification comprise the business logic, I recommend you outline how this process might have been performed as a paper-based workflow in the past.