Some backend decisions are made by the database, not by Java

When you start writing a backend, the entities usually look like the easy part. You create a few classes, add the relations and move on to the services. As the system grows, you realise the database decisions you made outlive the Java code.

Whether a value has to be unique, which columns form a key together, whether history is kept or only the latest state — all of it turns into business logic later.

Entities do not settle everything

Working with JPA is comfortable. You write the relationships, create a repository and handle the data as objects. That comfort makes it easy to forget that the database has rules of its own.

When I look at a data model now, I try not to stop at “which entity is related to which”. Questions like “is a second copy of this record allowed to exist?”, “do we need to know the previous state?” and “can this operation be repeated?” matter more.

Because once the database enforces the rule you were enforcing in application code, another part of the system cannot break it by accident.

A simple schema changes a lot later

In the first version everything looks simple. Then audit, reporting, concurrency and real use arrive. That is exactly when the early database decisions show their price.

So when I build a new system now, I do not treat the database as the place where Java entities are stored. It is part of the system's rules.