2021 02 19 Протокол

1. ПО фрактально, т.е. разные уровни (метод -> класс -> модуль -> компонент -> подсистема) можно обобщить и единообразно представить в виде "вход -> преобразование -> выход". Если разделить "входы" на два типа: запросы (просто возвращают информацию о состоянии) и команды (изменяют состояние системы), то очевидно, что состояние системы на любом уровне в любой момент можно определить, проиграв всю последовательность команд. Если унифицировать интерфейсы и описать формат команд, то можно задавать для любого фрагмента системы любое требуемое состояние с помощью списка единообразно составленных команд.
   • единственный вход в приложение - поток событий (единый формат)
   • выход в формате xml + xsl - помогает описывать преобразования в любой выходной формат для фронта
   • тиражирование этого принципа на всех этапах декомпозиции системы вплоть до unit тестов
   • ограничение доступности операций помогает фильтровать и валидировать поток событий
2. Если на каждом уровне каждый фрагмент системы обладает "функциональной чистотой", т.е. каждый раз выполняя одну и ту же команду приводит к одному и тому же состоянию системы и при этом не содержит побочных эффектов (влияние на состояние других фрагментов), то функциональность системы в целом можно уверенно протестировать, зная все допустимые комбинации "вход-выход" для всех фрагментов.
3. Функциональная чистота и унификация интерфейсов - прямая дорога к переиспользованию фрагментов системы (опять же, на любом уровне). Чем более высокоуровневым является переиспользование, тем эффективнее выполняется разработка ПО, т.к. тем большая часть функциональности просто подключается к системе в виде переиспользуемых фрагментов.
4. При проектировании движка настолок мы можем двигаться "сверху-вниз" и "снаружи-внутрь" одновременно. "Сверху-вниз" означает, что мы начинаем с очень высокоуровневых бизнес-целей и вариантов использования, постепенно декомпозируя и выясняя, какие еще фрагменты функциональности остались неспроектированными. "Снаружи-внутрь" больше относится к реализации, но тем не менее - начинать декомпозицию нужно с действий пользователя (внешняя граница системы, "вход" в наших терминах) и двигаться "внутрь" системы, определяя требуемую на более низких уровнях функциональность.
5. Дальнейшей проектирование договорились продолжать в части исследования предметной области на примере конкретной игры из списка игр:
   • общее видение системы возможных событий (в терминологии событий, подаваемых на вход)
   • алгоритм действий для определенного типа событий
   • какие сущности нужно создать
   • какие связи сущностей между собой появляются в процессе обработки событий
6. Мержить идеи:
   • алгоритмы, предложенные в процессе исследования, разбить на функциональные блоки
   • функциональные блоки объединить в подсистемы
   • для подсистем выбрать язык реализации
   • собрать итоговую модель данных