Architecture. How correct is it to store non-database data in Entity?

Question

Java

Hello!
I am writing an application on Spring Boot/Spring Data.
Let's say I have a "model" class which is Entity. Its fields correspond to the fields of records in the database and are read in the usual way through the repository.
I want to add a number of fields to this class that are not in the database (declare them as Transient) and which I need to store intermediate values, flags, etc. It's convenient for me. it's easier to work with a single object than with two/three. But how correct is this from the point of view. architecture? Do they do that at all? What problems can come up here? And if not, how do they usually solve such problems?

Answer 1

In principle, you can, no one will shoot you for this. Problems - it all depends on the scale of your application and the requirements for further support and changes in the code. I don’t see anything directly serious that will always or almost always come out in this story.

Answer 2

I would make another EntityTo class and inject Entity into it and enrich it with fields.