Многие хотят попробовать себя в роли архитекторов, но не очень понимают с чего начать.
Много раз видел как программисты, желая показать "архитектуру", отдавали схемы классов и связей между ними, думая что этого достаточно.
Проблема в том, что схема классов — это уровень кода. Самый последний уровень, который избыточен и не нужен.
Начинать проектирование с него — всё равно что строить дом, начиная с выбора дверных ручек.
В прошлой статье мы разобрали первый уровень модели C4 — System Context.
Он общий почти для всех игр на Unity, достаточно абстрактный и содержит мало конкретики.
Сегодня поговорим про второй уровень — контейнеры.
🔸Что такое контейнер
Контейнер в модели C4 (никак не связано с Docker!) — это приложение или хранилище данных. То, что должно быть запущено для работы всей программной системы.
Ключевой критерий: контейнер — это независимо деплоемая единица.
Примеры контейнеров:
▫️ Серверное приложение — http или любой другой сервер с логикой системы
▫️ Клиентское web-приложение — админка для управления данными пользователей
▫️ Мобильное приложение — бинарник, который пользователь скачивает на телефон
▫️ База данных — SQL или NoSQL решение для хранения данных игроков
Т.е. после того как у тебя готов общий уровень системы, ты определяешься какие элементы будут публиковаться и деплоиться независимо друг от друга.
Берёшь каждый элемент системы и разбиваешь его на отдельные деплоемые части.
🔸Пример: сервер для маленького проекта
Вот как бы я принимал решение о том, как сделать небольшой игровой сервер (< 100k скачиваний и 1k DAU).
Прикинем нагрузку. RPS на таких объёмах будет достаточно низкий:
1000 [игроков] / 24 [ч] / 60 [мин] / 60 [сек] ≈ 0.01 req/sec
Одного экземпляра http сервера на любой технологии будет более чем достаточно.
Значит всё серверное приложение — это 1 docker image, который можно опубликовать в Yandex/Google/Amazon Compute Cloud.
Сделав так для каждого элемента системы, ты получаешь понимание какие части как будут деплоиться.
Это формирует достаточное понимание того, как вся система будет функционировать.
🔸Практические рекомендации
🔹 На крупных проектах может быть огромное количество элементов. Нет смысла упарываться в детализацию всех контейнеров всех элементов системы. Указывай только то, что нужно конкретному проектируемому элементу. Зависимости вне твоей зоны ответственности уточнять не нужно.
Пример из Hero Wars: для чата мы используем MQTT сервис, на топики которого подписывается клиент чтобы получать новые сообщения. Когда я проектировал чат, я не уточнял из чего состоит MQTT сервис и что он использует внутри — это избыточно и вне моей зоны ответственности.
🔹 На этом этапе полезно прописывать технологии, если они важны для проектируемого сервиса.
Для того же чата на серверной стороне для общения сервисов между собой используется Kafka.
Решение о том как организовано взаимодействие сервисов уже принято — указываем конкретную технологию, упрощаем схему и делаем её более информативной.
🔹 Unity-клиент на этом уровне детально не проектируется.
Любое Unity приложение — это монолит и всего 1 деплоемый unit.
Максимум что можно указать на схеме — платформы куда деплоимся. Но в большинстве случаев это избыточно.
🔻Проектирование можно и нужно начинать с двух простых шагов: сначала система и её ключевые элементы, затем уточнение каждого элемента деплоемыми unit'ами и технологиями.
Так ты получаешь не просто каркас, а полноценное верхнеуровневое понимание функционирования всего приложения.
Это вторая статья серии про проектирование. Дальше: компоненты и код.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect