Некоторые backend-решения принимает база данных, а не Java

Когда начинаешь писать backend, сущности обычно кажутся самой простой частью. Создаёшь несколько классов, добавляешь связи и переходишь к сервисам. Но с ростом системы понимаешь, что принятые решения по базе живут дольше, чем Java-код.

Должно ли значение быть уникальным, какие колонки вместе образуют ключ, хранится ли история или только последнее состояние — всё это позже превращается в бизнес-логику.

Сущности решают не всё

Работать с JPA удобно. Пишешь связи, создаёшь репозиторий и обращаешься с данными как с объектами. Из-за этого удобства легко забыть, что у базы есть собственные правила.

Глядя на модель данных, я стараюсь не останавливаться на вопросе «какая сущность с какой связана». Важнее оказываются другие: «допустима ли вторая копия этой записи?», «нужно ли знать прошлое состояние?», «может ли эта операция повториться?».

Потому что когда правило, которое вы держали в коде приложения, держит база, другая часть системы уже не нарушит его случайно.

Простая схема потом меняет многое

В первой версии всё выглядит просто. Потом приходят аудит, отчётность, конкурентный доступ и реальная нагрузка. Именно тогда становится видна цена ранних решений по базе.

Поэтому теперь, собирая новую систему, я не считаю базу просто местом, где лежат Java-сущности. Она часть правил системы.