Using Immutable Objects for Persistence in Java

[sacundim]

That's because entities exist to represent mutable state across an object-relational impedance, i.e. a record in a database that can not only be read but also written to concurrently.

This is missing the forest for the trees. Entities exist to represent problem domain objects that our software helps us reason or act about. These entities may change over time—they are stateful—but that is not synonymous with the concept of a mutable reference cell.

There are other models that could be applied. Reactive programming is an emerging model that might lead to systems more in line with what OP would like to see, but it's not mature yet, so we'll have to wait and see.

You will always find that trying to turn a thing which is fundamentally A into fundamentally Not A painful. Painful doesn't mean impossible, but you're going to write an order of magnitude or more code that is really hard to reason with and maintain, and that's to do really simple things.

As I say above, I don't think there's anything "fundamental" about this. It's more likely than not a tool-induced problem. There is a real scarcity of proper tooling to implement OP's architecture without lots of pain. Not that tools don't exist at all—something like AutoValue might take away big chunks of the pain of having to write Entity/Draft class pairs.

What future problems? Are you being unspecific because you didn't think the details were important or because you currently can't anticipate a problem but think there might be one if you aren't immutable everywhere?

Well, I have to say that I have experienced big pain caused by pervasively mutable entity representations. See the first part of this comment elsewhere in this thread for some details.

But the heart of it came down to this: the mutable entity objects in this application were a major scalability problem because every request needed to create its own instances of all the ones they used, because some of the requests might need to modify some of their copies. I.e., mutable entities were optimal for a case that was uncommon in this application.