What is a business rule and an enforcement rule? What defines a mechanism as one or the other?

Asked

Viewed 296 times

3

I know that has question about it in general. But I want to be specific.

When creating a business class, a Cliente for example, it makes sense to have parts of the mechanism, such as 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 mechanism together with the business object)? I mean, why can I have GetHashCode(), ToString(), Equals() that are not part of the business rule, and has a "rule" saying that I can not mix business rule with application?

All called Patterns design are rules of application and have placed on objects that are rules of business.

Another example is a system of events that can shoot at other objects, makes conceptual sense independent of its functionality and usefulness?

Clearly these are mechanisms of application, even of language. I see this all the time, but I also see that some say they can’t have things of persistence in this object because it’s an application mechanism and it’s not part of the business model. Because some things of application mechanism may and others may not?

What is the line that defines what is each thing and what may or may not?

Another example based on a posted answer: why should the maximum number of characters be the rule? Why is it not a business rule? Or is it? And more importantly, why do these things get mixed up in the same object if they are clearly responsibility? Some things get mixed up, even if this is not the case.

There are other examples that can demonstrate more clearly what each thing is?

software-engineering paradigms business-rule

2 answers

0

Hi, I hope I’m clear. Business rules relate to how the process that the software will implement works.For example, imagine that your software will automate the Rh of any company, business rules would be the rules that Rh already uses and could be from how files should be named to access rights to the system and etc., in general relate to how the process is structured.

Application rules are generally related to its implementation and its limitations, 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 database).

  • This is already in the link I posted, I asked something else. Do not limit to read the title of the question. But I’m going to use your example to help understand the question. I edited it, see.

0

My perception is that separating the concepts of business rule and application becomes simpler as more agents are added to the scenario. During the software requirements survey stage, it is natural for the analyst to opt for the use of an API/Backend to, in addition to persisting information, coordinate the data flow. Access control, for example, is a business rule defined once and imposed on all customers. If you are modeling a monolithic service that does not provide reusability of rules between modules or applications, the boundaries between application and business characteristics tend to be less defined.

some say they cannot have things of persistence in this object because it is an application mechanism and is not part of the business model.

Naturally, the business rules are inherent to the domain in which it is working and are related to the processes of the business model - a "customer registration" operation is to business rule as "browse to customer registration" is to an application operation.

My understanding of the concept of business rules takes such rules away from the technological means to implement them. This answer for a question similar to yours, but in English, speaks something with which I agree a lot: "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) specific implementation problems related to the application.

Another aspect is that the business rule is relevant and common to all applications that use it, so it could be shared between them - like if you develop two complementary applications (say a mobile app and a website) that depend on the same business rules. Sharing enforcement rules may not make as much sense in this case.

Why should the maximum number of characters be the rule? Why is it not a business rule? Or?

Imagine a system 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 a document number, either CPF. The rule of business 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 score/input mask.

To answer the question, it could 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 instead of computers? If yes, then I see it as a business rule.

Expanding my own question above: if the scenario were just another platform (replacing my Mysql database with Postgres, for example), would the character limitation change? If not, point to business rule. If so, I should probably have better modeled my implementation so that the functionality of the application did not depend so much on technical aspects.

Updating:

My main doubt is what is the limit of things and why it is preached to separate and all the time the codes join these things [...]

To be honest, I think this is another case of "do what I say but don’t do what I do" in the world of software development. We know the standards, the best practices, but we do not always apply them, either because of lack of time ("you have 2 months to develop this system, but it’s been 6 weeks"); or because of the amount of Boilerplate or complexity that these indicated implementations can cause.

What do you mean complexity? Boilerplate?

I refer to small applications, although the understanding of this term varies widely from dev to dev. Well, when adding a method to, citing your comment, "take an object hash" (and even do a validation on top of that) I wonder: this will be used somewhere else? Some possible answers in my projects:

  • Not, is relevant only to this functionality and there is no provision to reuse any portion of it. So I implement right there.
  • No, but this section/method does not belong to the scope I am working on (here comes the separation we are talking about). But it is overworking to create a layer/class/interface for a 5-line method... I will keep it here, or, with the simplest possible implementation, put it in another file/package.
  • In the future, maybe. I am 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 moment on, the only way to avoid copy-and-ola is by writing reusable code. There is now an implicit need to follow good practice, separating responsibilities more clearly.

The complexity I refer to is subjective and quite opinionated. Creating an application "layer" for some simple programming just to "follow the pattern" is indicated, but the programmer might wonder "I really need to create an interface here and I’ll probably only have one concrete class"? This is a recurring question when I’m, for example, limited to Java 7 while creating my Android app. How many lines of Boilerplate would be saved if you could use Lambdas instead of an anonymous class?! Maybe it’s a particular exaggeration of mine, but sometimes my search for "simplify architecture" ends up taking some shortcuts and discarding good practices that would be more verbose.

DRT;

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 (therefore it could be improved in the future).

  • But monolithic or not everyone uses rules of application along with business, including most languages makes it impossible not to do this, just like most frameworks that people use. Taking from his text: "Business Logic is Logic, that is created with Collaboration and Agreement with business experts", then why an object Cliente has things like catching a hash of the object, transform into string, compare two objects, add one Subscriber to an event and shoot it? This is the question. This all explains the differences, but not why every code mixes both.

  • The answer focuses more on showing why it is good to separate, and this I know, including because Linkei an answer that speaks of it (though it is not even my reference to know it). My main doubt is what is the limit of things and why it is preached to separate and all the time the codes gather these things, as the examples I gave. The good part of the answer is that the rule would exist in another scenario. This seems to be a relevant criterion of choosing what each one is, but still missing because people mix the two as they run with the Object and the event (Observer Pattern)

  • I updated my answer.

  • It got better, but the question of hash, You have no option, the language defined that is so. Now, if the language says it’s that way, then the "rules" of separating the rules of business and application are not so important. And if it is, why do they make you do it? The same for a system of events and several others Patterns design that people apply that are application mechanisms and are there next to the object that should be only business. In the case of the hash, you can even delegate the implementation, but the contract is there in the business object (just to take this example).

  • So I just don’t agree with the part that says it would be limited resources, and the question is arose precisely because it’s not the case, there is a technical determination or rule taken as absolute to do this. That is why I cite the example of the mechanism of Object be in all objects. Everything in it is mechanism of application, of language, it is not of business, but it is there. And I quote the events that in general is not something of the language, but is everywhere as something to be done always this way. I could have spoken of others Patterns design that people use not because they have no time to do better.

  • My understanding of the inheritance of Object is that because it is a language mechanism, we cannot dissociate it from the business rules (therefore it is necessary for a concrete implementation). The line that defines the limits on the mechanisms that can (or cannot) be used depends on the language/technology (unfortunately I cannot elaborate this aspect). Back to hash, I see that it would be possible to abstract it without delegating its implementation, simply encapsulating the business object in another, now in an application layer. Here comes my point about complexity: in practice, it pays?

  • On "separating business rules and application is not so important," my particular view is that standards in general are recommendations and serve to guide the programmer. They are very important for outlining development, but they are not the obligations of those who write the code. It is a particular aspect of design and professional, since there is no standard that meets universal needs.

Show 2 more comments

Browser other questions tagged software-engineering paradigms business-rule

You are not signed in. Login or sign up in order to post.