Критично в том то и дело

ну такое

консистенция довольно важна

Поэтому такие запросы есть и можно использовать реальный кэш

Обычно не всего.

Смотрите. Простейшее упражнение.

Берем некую условную современную реляционную БД. Да пусть даже MySQL, если вам так хочется.
Читаем ТЗ:
- в базе данных хранятся оценки за домашние работы, оценка - это число от 1 до 5
- оценки могут быть поставлены только существующим студентам
- оценки выставляются сразу всем студентам за один урок, недопустима ситуация, когда кому-то оценка выставлена, а кому-то нет
- сразу после выставления оценок должна автоматически заполниться таблица со средними оценками за месяц

Я беру СУБД и использую:
- доменный тип
- внешний ключ
- транзакции
- представления

После чего у меня большая часть ТЗ выполнена на уровне БД, причем я гарантировал ненарушение граничных условий.
На долю PHP осталось только банальное запись-чтение

А теперь замените РСУБД на, к примеру, просто файлики. Тупо сторадж. И сделайте мне такое же. С теми же гарантиями.

Разумеется, пример самый примитивный. В реальности всё гораздо сложнее.

Само собой не всего. Мало даже чего

Нет, это просто не кэш.

Идея иметь две БД: одну оригинальную для сущностей и вторую быструю с удобно разложенной копией данных для выборок. И синхронизировать по событиям.

Ну вот и дели, как нужно. И вообще задержка будет меньше 1сек обычно. Это думаю норм

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

Ограничения. Чем их больше, и чем более они явные - тем лучше.
И обычно именно с ограничений на данные начинается проектирование приложения.

идею понял, спасибо, тогда согласен, но тогда это скорее "хранилище на стеройдах", нежели "не хранилище" =)

да это просто банальная РСУБД, которые используются последние лет 30 как ))

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

Спс. Я так и догадывался. Мне не по душе. Я считаю себя всё таки php программистом и модель бизнеса предпочитаю делать там же.

закладывайте, но это будет лишний код и лишняя себестоимость

то есть для оценок от 1 до 5 вы выберете bigint?

Такой подход есть безусловно только это не ddd. Это data centric design.

та, примерно так и понимал, теперь можно быть уверенным)

DDD идет следующим слоем
вам никто не мешает использовать сущности и агрегаты в коде приложения, предварительно на слое БД наложив ограничения на данные

Я сделаю ValueObject для оценки(от 1 до 5), покрою тестами. Создам агрегат для оценки домашней работы. Покрою его тестами. Потом подберу типы данных под проперти. Будет tinyint. Сгенерится структура. Готово