The basis of the code smell around the "data class" is that the instance manipulation logic is not in the class itself, so other classes seem to manipulate an entity that scatters the logic associated with the entity around the rest of the code base - violates the cohesion principle.
You can argue that data entities are a special case because, by the nature of ORM, most of the logic is performed by the ORM level (for example, it controls entity relationships). However, I do not find this argument convincing, because usually there is other business logic related to the entity that should definitely be encapsulated in one place.
In my programs, I usually find that entity classes contain basic methods for providing relationships between entities, such as “add a child to this object”, as well as property owners or other methods that apply real values. Then I create a separate business logic class that contains the business rules associated with the entity. This separation keeps the entity class simple (I found that entity mappings are quite confusing without complicating the class with business logic!), But it maintains cohesion by keeping business rules in one place.
One criticism of this approach is that by creating the properties of an object publicly to expose them to the BL class, it allows them to be manipulated by any other class, and you risk a failure in cohesion. This is valid criticism, but I overcome the risk with code reviews and some other methods (based on lambda-and-reflection) that make properties "semi-private" (see Description "Class for defining nested expressions" here for a starting point on how , how to do it).