НАПИСАЛ 3 СИСТЕМЫ АБИЛОК С НУЛЯ И ВОТ ЧТО Я ПОНЯЛ

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

1️⃣ Отделить данные от бизнес-логики
Т.е. объект игрока/героя/персонажа со всеми данными должны быть полностью отделены.

И это нужно не для тестирования или потому что так Дядя Боб завещал, а для свободной модификации в любом месте.
Данные ходят из слоя в слой из системы в систему по разными причинам:
🔸 Для отрисовки UI
🔸 Для отправки по сети
🔸 Для модификации в других системах
🔸 Для отката в предыдущее состояние
В случае десинхронизации клиентов или неправильным изменением данных (выход за пределы рабочих значений)

И если сделать данные частью какого-то объекта (агрегировать их) , то нужно будет таскать везде его.

Правила для легкой масштабируемости:
🔹 При добавлении контекста не связанного домена использовать композицию, не наследование.
Перегружать данные в наследнике = ломать совместимость моделей между системами/фичами.
🔹 Если работаете с сервером, то сначала принимаете данные, потом показываете изменение игроку.
Эта пауза необходима, иначе не будет времени проиграть все красивые анимации и эффекты.

Минусы:
— Нужно жестко следить за порядком изменения данных.
Модификация в неправильный момент может сломать всю логику.

2️⃣ Не создавать мелкий кипиш. 1 абилка - 1 класс для всей логики.
Вам не нужен этот SRP, вы заплатите высокой когнитивной сложностью системы (раз, два)

3️⃣ Порядок и правила применения в одном месте.
Бизнес-правила верхнего уровня (управление порядком применения/добавления/удаления/синхронизация) на верхнем слое в одном месте.
Весь кипишь с модификацией данных, проигрыванием эффектов, изменения UI и т.д. внутри.

4️⃣ Сервис абилок лишь предоставляет API для их применения
Он лишь выступает фасадом, что агрегирует в себе все сервисы по работе с абилками.
А внешние сервисы лишь вызывают методы в нужный момент игры (клик пользователя, ответ от сервера и пр.).

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

Что делает саму систему Clear (прозрачной) для понимания по Cynefin framework'у.
А значит легкой для работы и внесения изменений без сторонней помощи.

#проект_в_разработке@UniArchitect