Сложная бизнес-логика. Как всё учесть?

Question

[Ev Gen]

Здравствуйте. Ситуация такая. Есть игровой сервер
(2 части у сервера: обработка запросов пользователей и realtime обработчики (полёты, бои и др))
На данный момент:
- есть около 20 сущностей (корабль, флот, пользователь...)
- 50 типов запросов от пользователей (модернизировать корабль, создать флот...)
- 5 realtime обработчиков (полёты, бои, добыча...).

Если я хочу добавить новый тип запроса от пользователя (например удалить космический корабль), я должен учесть это во всех местах (в бою и в других запросах). Если я это где-то забуду, то появляется баг. Что будет через год? Когда будет 100 сущностей...
Как справляться с такой сложной бизнес-логикой с большим набором правил? Может есть какие-то инструменты или подходы?

СМ. комментарий

ответ: #comment_433231

Comments

[nirvimel]

У вас там вообще ООП используется? 20 типов сущностный хотя бы унаследованы от базового класса?

[Евгений Шатунов]

GLeBaTi , давай поподробнее. Сейчас все описание ничего не поясняет.
20 сущностей - каких? Что описывают эти сущности?
"я должен учесть это во всех местах" - зачем? Если ты это должен, глядя уже на это абстрактное описание, значит что-то с самого начала пошло не так.
Почему количество сущностей должно увеличиваться со временем?

[Ev Gen]

nirvimel: Евгений Шатунов: Владислав Килин:
Сущности: Корабль, Пользователь, Флот... (как таблицы в бд)
Запрос: КупитьКорабль
{
если
1) есть деньги
2) есть место во флоте
3) изучена наука
4) флот не в бою
то
1) списать бабки у пользователя
2) создать корабль
3) добавить корабль во флот
4) создать mailMessage
5) создать logEntry
}

К примеру добавляем возможность телепорта флота. Это нужно учитывать в запросах:
Создать корабль (нельзя если флот телепортируется сейчас)
Удалить корабль (нельзя если флот телепортируется сейчас)
Переместить флот (нельзя если флот телепортируется сейчас)
и др.

Таким образом создается ЗАПУТАННАЯ СЕТЬ ПРАВИЛ. Как держать эти правила в голове? Каждый раз смотреть все запросы и думать учитывается там или нет?

[nirvimel]

GLeBaTi:

Создать корабль (нельзя если флот телепортируется сейчас)

Это должно проверяться НЕ в самом запросе (который не должен ничего знать о возможности телепортации и других свойствах флота), а в методе addShip в классе Fleet (который неизбежно вызываться в ходе обработки запроса на создание корабля).
Если флот не может в этот момент принять корабль (в телепортации), то addShip выбрасывает исключение с текстом, который красноречиво говорит об этом.
Но сам обработчик запроса СreateNewShipRequest (или как он у вас называется) НЕ ловит это исключение (не нужно перегружать код по мелочам), оно пролетает насквозь к самому центральному роутеру, который разруливает все запросы клиентов и отправляет их на обработку. Тут В ОДНОМ МЕСТЕ перехватываются все исключения (определенного класса, или его наследников), всплывающие сюда со всех нижних уровней, из них достается текст сообщения и заворачивается в response для отправки клиенту (этот текст потом будет отображаться где-то на клиенте).

Вот залог правильной архитектуры: Добавили телепортацию для флота - это никого не должно волновать, кроме одного единственного класса Fleet, в котором инкапсулирована вся соответствующая логика.

[Евгений Шатунов]

GLeBaTi , сервер state-less чтоли?
От части nirvimel говорит правильно. Но его слова - это лишь вершина айсберга. Дальше, чтобы понять проблему и дать точное решение, тебе придется нарушить NDA (или мне придется его подписать) и рассказать мне все тонкости организации сервера. Только я не могу этим всем заниматься. :)

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

Дальше, чтобы вносить пояснения и передавать только нужную информацию, мне нужны вопросы от тебя.

[Ev Gen]

nirvimel: Наверное это то что мне подходит :)
Если мне все запросы связанные с флотом переносить в класс Fleet, то он сильно разрастется. Как мне решить эту проблему?

[nirvimel]

GLeBaTi: Не надо переносить в класс Fleet запросы, исполнение, которых затрагивает много разных подсистем. Флот должен заниматься только флотом, он не должен ничего знать об особенностях обработки клиентских запросов, о логгировании, об уровне науки (этими проверками должен занимается тоже отдельный класс); о кораблях флот должен знать самый минимум (остальное спрятать в методы самого корабля, то есть интерфейса Ship, который реализуют разные типы кораблей).

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

[Ev Gen]

nirvimel: проверку "изучена ли корабельная наука" мне куда лучше поставить? в метод fleet.AddShip() или в СreateNewShipRequest?

[nirvimel]

GLeBaTi: Если делать с расчет на расширяемость, то в объекте Player (в котором собрано все состояние игрока) должно быть поле класса Tech, который отвечает за состояние прогресса науки. У него должен быть метод типа isTechAvailable, который принимает id (возможно, строковое или enum) технологии и возвращает булево значение (доступна или нет). Только сам корабль "знает" технологию (ее id), необходимую для его создания, поэтому проверка идет в конструкторе конкретного класса корабля. Можно унаследовать все корабли от базового класса и реализовать проверку технологии (в определенном поле) в его конструкторе, тогда в производных классах останется только менять значение этого поля, но это оставляет возможность создания каких-то особенных кораблей, которые будут проверять технологии каким-то нестандартным способом, если переопределять не поле а сам метод проверки.
СreateNewShipRequest вынимает из клиентского запроса id (или имя) класса корабля и ищет его в специальной таблице (map), где ему сопоставлена ссылка класс, который можно инстанциировать (вызвать для него new). Все классы кораблей реализуют интерфейс Ship, поэтому для СreateNewShipRequest любой корабль выглядит как просто Ship (в реальности же конструкторы у всех разные). Если при вызове конструктора он не нашел соответствующую технологию, то из него выбрасывается исключение, которое пролетает насквозь все уровни, пока не ловится на самом верху и отправляется клиенту в виде строки. Таблицу, в которой именам/id кораблей соответствуют внутренние классы, можно сделать статической и добавлять туда новые корабли вручную, а можно пойти еще дальше и сделать еще более гибкую архитектуру, чтобы при загрузке модулей, каждый класс кораблей сам прописывал себя в таблицу (изначально пустую), тогда новые корабли можно будет добавлять в новых модулях, не меняя ни одной строчки в существующей кодовой базе.

[Ev Gen]

nirvimel: Спасибо!)

[Ev Gen]

nirvimel: не нашел как тут в личку писать, написал вам на habr. Гляньте если не затруднит :)

Answer 1

[nirvimel]

Несколько банальных принципов ООП (применительно к вашему проекту):
Сущности, которых касается определенный запрос, должны быть либо унаследованы от одного класса, либо реализовывать один интерфейс (в дополнение к другим интерфейсам), который имеет методы управления этими сущностными, необходимые для реализации этого запроса.
Запросы также должны быть сгруппированы в дерево классов или наследовать набор интерфейсов. Сущности могут взаимодействовать не с конкретными классами запросов, а с общими интерфейсами, которых не так много, как различных запросов.
То же самое с realtime обработчиками и, вообще, с любыми элементами логики.

Comments

[Ev Gen]

ответ: #comment_433231

Answer 2

[xmoonlight]

- есть около 20 сущностей (корабль, флот, пользователь...)
- 50 типов запросов от пользователей (модернизировать корабль, создать флот...)
- 5 realtime обработчиков (полёты, бои, добыча...).

По пунктам:
1. сущность = существительное
2. свойства объекта = прилагательное
3. тип запроса на действие к объекту = действие/глагол
4. real-time обработчик = триггер/heart-beat/time-tracker

Теперь, чтобы добавить что-то новое, просто используйте наследование объекта нужного архитектурного паттерна проектирования связей, созданного заранее.

Comments

[Ev Gen]

можно пример?

[xmoonlight]

GLeBaTi: конечно, в википедии - полно информации по паттернам. смотрите

Answer 3

[Владислав Килин]

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

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

Что касается вашего конкретного кейса, у меня создалось впечатление, что вас скорее интересует работа с единым хранилищем данных игровых объектов. Для этого тоже есть масса интересных решений, например Unidirectional Data Flow.
Хранение состояния игры в одном единственном месте, обращение к нему через прослойки-мапперы. Есть несколько вариантов реализации перехвата изменений - это может быть иммутабельное состояние, для которого достаточно будет считать дельту между старым и новым, публикуя изменения глобально, так чтобы участки программы, которым эти изменения интересны, сами их подхватывали, либо реактивное состояние, которое запоминает, кто к ней обращался за какими данными и уведомляет их о конкретных изменениях непосредственно в момент их применения.

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

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