Are business rules always related to validation?

Question

Since I started studying object orientation I hear a lot about business rules. Basically, from what I understand until today, an object must have methods encapsulated the rules of business and the modification of its state must be done through these methods and not through direct access to its attributes. From what I understand there is so much emphasis on this that an object without methods is even called anemic.

The biggest problem is that I still do not understand very well what are really these business rules. All the examples I’ve seen, the business rules have to do with validation. One of these examples is a class Usuario representing a system user, and the business rules imposed in the example have to do with validations of the data (ensure that the required data is informed, ensure that the email is a valid email, etc).

Another widely used example is the banking system and there the business rules are again validations: for example check if the account balance is enough to make a withdrawal and etc. So it seems that the business rules at all times are validations to verify whether a certain operation can be performed or not, or to verify that the data reported is really consistent.

Is this impression correct? Do such business rules always have to do with validations? If not, what really are business rules?

Answer 1

In fact it is very common that business rules are validations, but not necessarily.

The interpretation of what is a business rule and what is a mechanism is not always very clear (I asked a question and I did not get satisfactory answers), and depending on the methodology used there may be a preference for one thing or another.

In fact, if we think about the types of objects there are also disagreements about what should be part of the type as a business rule and what should be something external to the type still being a business rule. Often this is implemented through rules (Rules), restrictions (constraints), policies (policies) or treatments (traits). That are nothing more than other auxiliary types to the main type. Sometimes a mechanism of business rules is used for this.

Taking the example of the bank account, you already know the various validations that exist. But the object only validates data? It can not perform anything?

Let’s say you have a method called ObtemContasInativas(). Wouldn’t this be a business rule? It’s not validation. It states how an account is considered inactive and how to provide data about it. Note that what information and in what order are also business rules embedded within this hypothetical method. In fact it is possible that this method makes use of another to know whether an individual account is inactive or not, probably a EhInativa().

Most likely the first method is not in the bank account class itself, it would not make sense to be. But it is still a business rule. The second method already makes more sense to be in the type of own bank account. But not necessarily. There are a few reasons why you choose not to be. But this is not the case here.

Another method could be EncerrarConta() which could be called automatically by some event, perhaps verified by a method InativoMais180Dias() or manually by some system function. And she would obviously do a series of procedures to ensure that the account closes. These are all business rules.

Exactly how will access the database to get this information, to record what is necessary for the closure is probably part of the mechanism and does not enter these methods. They should delegate these specificities to other methods of mechanisms, most likely to other classes.

So it turns out that business rules can rather determine how information is obtained, how to perform certain algorithms, etc. It’s not just checks whether the data you’re trying to enter is right or wrong.

Even what to do in the case of an invalid input attempt can be a business rule by itself. It should log in? Should you call some auxiliary processing? You must change some state of some object?

Business rule is anything that determines what you should do in any situation by manipulating (reading or writing, full or partial) that information in an abstract form. In a way that makes sense to the user.

When manipulation becomes more concrete, such as WriteOnDataBase() or DisplayOnScreen() probably already part of the mechanism. Usually they are things that make sense to the developer only, but are fundamental for the system to work.

So you can validate, guarantee (slight semantic difference), record, query, classify, condition, relate, perform, verify, permit/prohibit, calculate, delegate, derive, signal, observe, etc. The amount of possible actions, even if generic, as listed, may continue.

Answer 2

Validations are, yes, business rules. But there are other.

Consider, for example, other bank business rules that go beyond checking the balance on the account before allowing a withdrawal:

A bank provides loans. You go to the bank and ask for 100 grand to pay in 10 times. The system will automatically assess whether you can take this loan and also the interest rate. To do so, the business rules of credit release are triggered. They include:

• A monthly portion of 10 thousand reais is more than 30% of your income?
• You have been a good payer on previous loans?
• The overall amount of customers with a similar profile has paid off their debts?
• What is the basic interest rate in force?
• ...

A complex calculation is made considering this and other information and the loan is released provided it is approved by someone with superior jurisdiction to your account manager. So this manager forwards the loan to approval, which goes into a queue and will be evaluated by another manager, which is also a business rule.