У меня как-то был пример такой сущности - для рефералки. Там по сути был айдишник и референс на парента. И рекурсивно ходило. И сложные вычисления внутри зависящие от уровня реферала. Оч удобно было тестить.

Строк 100-150 класс, конструктор, два метода, 2 свойства

Больше операций там не надо и данных тоже. Изолированный функционал. Данные не покидают сущность, логика на месте, анемии нет, здоровый (healthy) обьект

ну да, все логично

Или чекин ссылка для старта процесса. Ей надо рэйндж по времени когда ссылка валидна, и статус активирована она была или нет. Активация меняет время, мол так ссылка доступна 10 минут но если ты ее активировал можешь ещё сутки по ней заходить

Тоже ток метод activate который либо кидает ошибку либо пропускает ход

И так из таких малюсеньких блоков можно собирать систему

Emergence принцип

Как клетки в организме которые могут обмениваться химическими сигналами. Как Алан Кей ооп задумывал

Есть кейсы где логика отсутствует - профиль юзера например (имя, пол, дата рождения). Там можно все в имутабельный vo упаковать и заменять его целиком

я уж ты здесь, поделюсь....
На одно маленьком агрегате, который вообще по сути ни от чего больше не зависит, попробовала реализовать event sourcing
но какой-то свой es, скорее даже источник транзакций - принцип такой: имеем источник событий, но конечное события имеют не собственное состояние, а результат вычислений, т.е. мы получается сохраняем снепшот, последний результат id я записываю в отдельную сущность назовем её B, которая по сути имеем только собственный id и id этой самой последнего события, т.о. я имею возможность мягко удалить, также откатить, восстановить, иметь историю изменений
их минусов я пока вижу что при конкурирующем запросе мне все ровно приходится обновлять в сущности B - id последнего события, и по любому блокируем

Мммм я оч слабо понимаю. Приведи пример события.

ну смотри... Имеем некое количество, которое то пополняется, то расходуется, началное значение 100, получаем транзакцию о расходе -2, сохраняем событие не -2, а как результат 98

В целом в event sourcing у тебя агрегат в базе это стрим ивентов. То есть некий набор записей, каждая из которых имеет общую айдишку агрегата и версию. По версии можно делать оптимистичную блокировку. Так как все записи один агрегат то да надо лочить

и id этого события обновляем в B

Не, надо как раз хранить "убрали 2 добавили 4". То есть храним не ревизии стэйта а то что позволяет стэйт посчитать.

ну вот я и говорю, что какой-то собственный es ))

Добавили товар, добавили товар, удалили товар - итоговый стэйт считаем по всем событиям и получаем один товар в корзине.

Версионизация называется

Когда просто снэпшеты с версиями