Where should I put a calculation method? In the entity itself or in the business class?

Question

I have an architectural doubt, I believe.

I need to create a method that receives a period of dates and an entity in which to execute a search in the period cited. In fact, to ask this question it does not matter what the parameters of this method are. It is important to know that a calculation will be made in this entity using some algorithm.

The question is: where to put this method? In the very class that represents the entity or in the business class of that entity? I don’t know if I could express myself correctly.

I have heard of anemic entities, which would be entities only with the representations of the columns and nothing else, without business rules. How to decide this?

Answer 1

In the object orientation paradigm, an object in its most basic form has behaviors.

If an object has no behavior, it is nothing more than a data structure (whose Java statement and instance have the same form as the object statement and instance, so the difference is only conceptual).

If your entities are anemic (devoid of behavior), getting all business behavior delegated to other objects (which by the probable absence of business status itself will in fact be only classes grouping functions), you will be adopting in fact the Anemic Domain Model, which is, according to the view of some, something very far from Object Orientation (Please read the article to understand that, for Fowler, this is a anti-pattern).

Now, if your entities publish all the behavior relative to them, being delegated to other objects only the behaviors that do not belong naturally to any specific entity, then you will probably be closer to the Object Orientation paradigm.

If you want something more object-oriented, so to speak, then the decision of whether this method belongs to the entity itself or to another class depends rather on considering what the function of the method is, that is, on what the method will operate and what results it should produce. It is not possible to decide where the method should reside without knowing its function.

Answer 2

I think the answer is in the question. If you have one class for the entity and another for the business rules, you have no reason to put this method in the entity. The rule class is there just to have all the methods that affect that entity. In this case you keep the entity as anemic class.

But nothing in Hibernate requires this and many people consider it an exaggeration to have a separate class for business rule. If you think it’s good to reduce this complexity and just have the entity with the rules there, the decision is easy :)

What is best for your case I can not say. Try to experiment with both, even if not enough implement or put into production.

All programming is migrating to a more pragmatic view that adopts anemic classes whenever they are useful. Some people will not deviate from the earlier view that was mistaken, but increasingly we see a direction towards something less ideological at this point.

Answer 3

There is no right or wrong in this case, the architecture itself defines according to the solution you need to implement. If you extract all the business rules from your entity and create service/business classes, then the most interesting thing would be that this calculation would also be outside your entity.

But nothing prevents it from including business rules in entities, there are situations where an entity is developed so that it can "resolve" without depending on other classes, so the rules would be within the entity itself.