ПРОЕКТИРОВАНИЕ: КОНТЕЙНЕРЫ Многие хотят попробовать себя в роли архитекторов, но не очень понимают с чего начать. Много раз видел как программисты, желая показать "архитектуру", отдавали схемы классов и связей между ними, думая что этого достаточно. Проблема в том, что схема классов — это уровень кода. Самый последний уровень, который избыточен и не нужен. Начинать проектирование с него — всё равно что строить дом, начиная с выбора дверных ручек. В прошлой статье мы разобрали первый уровень модели 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