In fact, it is very common for business rules to be validations, but not necessarily.
The interpretation of what is business rule and what is mechanism is not always very clear, and depending on the methodology used there may be a preference for one thing or another.
In fact, if you think about object types 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, constraints, policies, or treatments.
/ em>). That are nothing more than other auxiliary types to the main type. Sometimes a business rules engine is used for this.
Taking the bank account example, you already know the various validations that exist. But does the object only validate data? Can not he do anything?
Let's say you have a method called ObtemContasInativas() . Is not this a business rule? It is not validation. It shows how an account is considered to be inactive and how to provide data. Note that what information and in what order are also embedded business rules within this hypothetical method. It is actually possible for this method to use another method to know if 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's still a business rule. The second method already makes more sense to be in the type of the bank account itself. But not necessarily. There are a few reasons to 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 checked by a InativoMais180Dias() method or manually by some system function. And of course she would go through a series of procedures to ensure the account is terminated. All of these are business rules.
Exactly how you are going to access the database to get this information, to record what is needed for shutdown is probably part of the mechanism and does not go into these methods. They should delegate these specificities to other methods of mechanisms, most likely in other classes.
Then one notices that business rules can rather determine how information is obtained, how to execute certain algorithms, etc. They are not just checks if the data you are trying to enter is right or wrong.
Even what to do in the event of an invalid data entry attempt can be a business rule per se. Should you log in ? Should I call some auxiliary processing? Should some object state change?
Business rule is anything that determines what you should do in any situation by manipulating (reading or writing, total or partial) that information in an abstract form. In a way that makes sense to the user.
When the manipulation becomes more concrete, such as WriteOnDataBase() or DisplayOnScreen() are probably already part of the mechanism. These are usually things that make sense to the developer only but are critical to the system.
So you can validate, guarantee (slight semantic difference), register, consult, classify, condition, relate, execute, verify, allow / prohibit, calculate, delegate, derive, signal, observe, etc. The number of possible actions, even if generic, as listed, may continue.
