What is business rule and application rule? What defines a mechanism as one or the other?
I know that has question about this in general. But I want to go to the specific.
When you create a business class, a Cliente for example, it makes sense to have engine parts, such as those of Object (I know that most languages have this by default, the question is whether it is a correct concept to have something that is language engine next to the business object)? That is, why can I have GetHashCode(), ToString(), Equals() that are not part of the business rule, and has a " rule" saying I can't mix business rule with application?
All so-called design patterns are application rules and have them put into objects that are business rules.
Another example is a system of events that it can trigger to other objects, does it make conceptual sense regardless of its functionality and usefulness?
Clearly these are mechanisms of application, even language. I see this all the time, but I also see that some they say they can't have persistence stuff on this object because it's an application engine and it's not part of the business model. Why some application engine things can and others can't?
What line defines what each thing is and what can or can't?
Another example based on posted answer: why should the maximum number of characters be application rule? Why is it not business rule? Or is it? And most importantly, why do these things get mixed in the same object if they are clearly responsibility? Some things get mixed up, even if this is not the case in this example.
Do you have other examples that can more clearly demonstrate what each thing is?
2 answers
Hello, I hope to be clear. Business rules concern how the process that the software will implement works.For example, imagine that your software will automate the HR of any company, the business rules would be the rules that the HR already uses and could be from how the files should be named to the access rights to the system and etc, in general they concern how the process is structured.
Application rules are generally related to their implementation and the limitations of the same can be defined by the platform used(the system can accept only some image formats) or by the implementation developed (maximum number of characters defined in the bank).
My perception is that separating the concepts of business rule and application becomes simpler as more agents are added to the scenario. During the requirements survey step of a software, it is natural for the analyst to opt for the use of an API / Backend to, in addition to persisting the information, coordinate the flow of the data. Access control, for example, is a business rule defined once and imposed on all customers. If you are modeling a service monolithic that does not provide for reusability of rules between modules or applications, the boundaries between application and business characteristics tend to be less defined.
Some say they can't have persistence stuff on this object because it's an application engine and not part of the business model.
Of course, business rules are inherent to the domain in which you are working and are related to the business model processes-a operation "register customer" is for business rule as "navigate to customer registration" is for an application operation.
My understanding of the concept of business rules distances such rules from the technological means to implement them. this answer to a question similar to yours, but in English, speaks something I very much agree with: " Business logic is logic, that is created with collaboration and agreement with business experts". Well, the expert in question does not care about (and probably does not even know about) specific implementation issues related to the application.
Another aspect is that the business rule is relevant and common for all applications that use it, so it could be shared between them - as in the case of you developing two complementary applications (say a mobile application and a website) that rely on the same business rules. Share application rules can don't make so much sense in that case.
Why should the maximum number of characters be application rule? Why is it not business rule? Or is it?
Imagine a systems integration scenario, you're building a client application of a government service, say the IRS. Your application needs to query a person's data from the number of a document, be it CPF. The business rule says that the CPF has 11 numeric digits, and that is immutable. In the application rule, focusing on an interface context, a CPF can have 14 digits, if we include the input score / mask.
Answering the question: it can be both. My criterion for separating the business rule from the application rule would be: would this character limit still exist if the rule were implemented in another scenario, such as on paper rather than computers? If yes, then I see it as a business rule.
Expanding my own question above: if the scenario were it just another platform (swapping my MySQL database for Postgres, as an example), would the character limitation change? If not, point to business rule. If so, I probably should have modeled my implementation better so that the functionality of the application did not depend so much on technical aspects.
UPDATE :
My main question is what is the limit of things and why it preaches separate and all the time the codes put these things together [...]
To be honest, I think this is more of a case of the "do what I talk about but don't do what I do" of the software development world. We know what the standards are, the good practices, but we do not always apply them, either for lack of time ("you have 2 months to develop this system, but it has already been 6 weeks"); or for the amount of boilerplate or complexity that these implementations indicated may cause.
As so complexity? Boilerplate?
I refer to small applications, although the understanding of this term varies greatly from dev to dev. Well, when adding a method to, quoting your comment, " take a hash of the object "(and even do a validation on top of that) I wonder: will this be used somewhere else? some possible answers in my projects:
- not , it is relevant only for this functionality and there is no forecast to reuse any excerpt from it. so I implement right there.
- No, but this snippet / method does not belong to the scope I am working on (here already enters the separation we are talking about). But it is overworking to create a layer / class / interface for a 5-line method... I will keep here, or, with the simplest possible implementation, put in another file/package.
- in the future, maybe . looking for an alternative that does not significantly increase the complexity of the project and implement the code in a way that can be reused.
- yes / Yes, why. From that point on, the only way to avoid copy-and-paste is by writing reusable code. At this time, the need to follow good practices is implicit, separating responsibilities more clearly.
The complexity I am referring to is subjective and quite opinionated. Create a " layer" from the application to some simple programming just to "follow the pattern" is indicated, but the programmer may wonder "I really need to create an interface here being that I will probably only have a concrete class"? This is a recurring doubt when I am, for example, limited to Java 7 while creating my Android application. How many rows of boilerplate would be saved if you could use lambdas instead of an anonymous class?! Maybe it's a particular exaggeration of mine, but why sometimes my quest to" simplify architecture " ends up taking some shortcuts and discarding good practices that would be more verbose.
TLDR;
My empirical understanding of why application and business rules end up mixed is that programmers have limitations (time, resources, knowledge) that require such measures, and software is often seen as something that will always require maintenance (so it may be improved in the future).