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

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

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

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

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

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

GLeBaTi:

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

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

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

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

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

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

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

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

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

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

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

nirvimel: Спасибо!)

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