А, это понятно, разделение на контексты, хранение нужного среза модели в своём контексте, evential consistency через шину между контекстами, это все понимаю и знаю, речь шла скорее именно про сборку состояния сущности перед тестом, или в фикстурах минимальным количеством кода

ну тип в фикстурах да, всякие штуки для упрощения управлением стэйтом есть, я больше про юниты говорил.

Событие удар, в котором мы раскрываем данные, которые потом улетают в некий сервис перемножающий факторы. Чем это лучше геттера?

тем что это можно представить как пайплайн сообщений)

что такое геттер? я не совсем понимаю на терминах боя

А оно нужно?

и геттер чего?

Вы предлагает данные юнита (2 проперти: атака, крит) через события удар передать в некий сервис. Чем хуже эти проперти геттером отдать?

я предлагаю передать удар

и не в сервис

оно позволяет получить линейный поток данных который могут обрабатывать чистые функции... экто получает сообщение с данными, обрабатывает, кидает новое сообщение дальше. так куда больше гибкости и меньше связанности, меньше проблем с temporal coupling (когда ты геттером достал а там уже поменяли)

Удар это событие, которое содержит атаку,крит шанс.

Верно?

Ну если это не интепрайз, чем не поток данных просто вызывать процедурщину друг за другом?

Мы события / слушателиджолжны потом связять - это не связность ли?

связанность она не абсолютна. связанность выше ниже - это про вероятность изменения контрактов по сути. "нет связанности" - компоненты просто не взаимодействуют никак. твоя цель снизить вероятность каскада изменений. А еще есть момент того что стэйт в твоей системе может быть нужен в разных местах - то есть мы начинаем зависеть от времени когда стэйт в памяти появился

я просто предположил, надо подумать в каком виде
может быть просто удары бы летали туда сюда

а может и не через удары проектировать

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

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

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

ну мол не так много надо что бы словить проблемы - достаточно просто иметь "базу данных" и/или необходимость скейлить твою игру больше чем на один запрос за раз.

Я вот просто не пойму профита между :

$data = $unit->gatAttackData()
$damage = $atackService->calculateDamage($data);
$unit2->damage($damage)

и

$dispatcher->listen('attack', fn($event) => {
  $damage = $service->calculateDamage($event->getData());
  $unit2->damage($damage)
})
$event = $unit->attack($unitId);
$dispatcher->dispatch($event );