What is Application Rules and what are the differences with Business Rules?

Question

According to the definition of this website:

Business rule is what defines the way to do business, reflecting internal policy, the defined process and/or the basic rules of conduct. That is, it is a set of instructions that users already and that the system to be developed should contemplate.

In projects that implement the MVC standard all business rules are implemented in the Model, however, reading the reply user’s Caffè I came across the term Application rules, and I realized in the answer that app rules are treated differently from business rules.

My doubt is about what is in you Application rules and what differences it has in relation to business rules?

Answer 1

The layers of a system

Ordinary software, such as a web application, for example, can be divided into a few conceptual layers:

• Interface
• App
• Business
• Infrastructure

There are systems in which some of these layers get a little confused, there are others in which they are very well delineated and there are still others that segregate some of these layers into more layers; and the names of the layers can also vary. But these 4 layers are the basics of a system that seeks separation of responsibilities.

Business Layer

In this layer is the code that represents the business concepts and is where the state of business is manipulated.

If the system specializes in controlling a bank current account, for example, it is in the code of this layer that debits and credits are made in an account, it is in this layer that the account balance is calculated, and therein lies the code that will not allow a debit greater than the available balance.

Application Layer

The code in this layer receives requests from the interface layer and coordinates the components of the Business layer to process these requests.

Following with the example of bank current account control, the user informs the data of a payment on an internet banking page (the page belongs to the Interface layer) and clicks on "send". This request will be received by an application layer code, which in turn knows which business component is responsible for processing the payment order.

After invoking the business component by passing the payment data, the application layer returns to the user a page informing the success of the operation, or another page informing the error.

This knowledge of which page to return to the user is an example of application rule.

Let’s say a new requirement determines that when a payment order is refused for lack of balance the user is informed of his available balance. Note that nothing will change in the business layer - it will continue to control the current account the same way it always did.

Already the application layer, which before simply returned a page with the error, now you must first get the available balance and then return a different page, which will also show the amount of the balance.

The requirement "When payment is refused for lack of balance, show the user your available balance" constitutes an application rule.

Difference between business rules and application rules

In a system where concepts are separated, the business layer knows as if you solve a problem and the application layer knows only whosoever (which business component) solves the problem.

The app layer has little code and no business knowledge - she doesn’t know how to process a payment, she just knows who can do it. She doesn’t know the restrictions that can make processing impossible, she only knows what to do with some of the errors returned by processing.

The business layer changes the state of the system in several ways to solve a problem, and delivers information about this state. The application layer doesn’t know the state of the system - it needs to ask for the business layer.

The application layer defines the flow of user interactions.

The flow below is an example of app rule:

• 1) Order the business component to process the payment.
• 2) If the business component returns success, redirects the user to the success page.
• 3) If the business component returns error:
• 3.1) If the error is insufficient balance, get from the business component the available balance, shows the error and the balance.
• 3.2) If the error is any other, it simply shows the error.

Business Layer Defines Problem Solution Flow.

The flow below is an example of business rule:

• 1) Validates the payment order data.
• 2) Check by schedule if the order can be processed immediately or if you will have to wait for the next business day.
• 3) Check for available balance.
• 4) Debit from account the payment amount.
• 5) Send the payment to the queue to be executed.

Another example

Just to shed some light application rules are not limited to determining user navigation on a Web system:

I worked on a system that ran several business processes.

There were processes that were activated by receiving messages from a message queue system (Message Queueing) and there were other processes that were executed at regular intervals, every few seconds.

In this case, the mechanisms that determined the timing of the process were application rules, and the processes themselves were business rules.

More examples of rules that are usually of application: authentication, authorization, management of licenses, export of files, sanitization of user entries, conversion of data types entered by the user, customization of the presentation according to the role of the user, integrations between systems.