Устроился в Nexters, где сейчас переписываю внутриигровой чат со старой технологии на новую. Проектирую его как отдельный dotnet микросервис и должен встроить в существующую архитектуру.
Впереди согласование с техническим директором, бэкенд-лидом, CTO — защита решений, проектирование, реализация.
И вот смотрите... Многие думают, что архитектура — это архитектура кода. Паттерны, классы, модули. Но это не так.
Когда тебе нужно объяснить команде что и как будем делать, когда сервера еще нет, а решения принимать надо — расписывать детали реализации бессмысленно.
Тут важно отодвинуться назад и посмотреть на картину целиком. Понять, как фича встраивается в общую систему.
Только после этого можно переходить к деталям.
🔸Уровень 1: System Context
Любая компания — это система. Набор элементов (отделов, команд, unit'ов), которые взаимодействуют между собой ради глобальной миссии. Для игровой компании — развлечение пользователя.
Для контекста, перечитай (А|а)рхитектура.
На уровне системы нам важно отобразить:
— Пользователя и его способ взаимодействия с системой
— Ключевые элементы, благодаря которым фича будет работать
При этом нас НЕ интересуют детали реализации и конкретные технологии.
🔸Пример: мобильная игра
Общий вопрос для начала:
Кто пользуется системой и что является точкой взаимодействия?
— Пользователь: игрок (Gamer)
— Точка взаимодействия: мобильное приложение (Game)
Какие ключевые элементы обеспечивают работоспособность системы?
У любой игры среднего размера (100к+ скачиваний) есть:
▫️ Tech Monitoring — Firebase Crashlytics, Unity Cloud Diagnostics, Sentry
▫️ Analytics — Google Analytics, Facebook, AppsFlyer
▫️ Game Data Service — админка с доступом к данным пользователя. Обычно своя разработка или MBaaS (Mobile Backend-as-a-Service): Firebase/Unity Cloud Save, AWS Amplify
▫️ Data Storage — хранилище данных пользователя
▫️ CDN — Content Delivery Network для ассетов и конфигов
Из комбинации этих элементов ты можешь собрать архитектуру уровня системы для 99% мобильных игр.
см. картинку или оригинал
🔸Модель C4
Поздравляю, первый уровень модели C4 освоен .
Software System — наивысший уровень абстракции, описывающий нечто, что приносит ценность пользователям.
Это то, что строит одна команда разработки, владеет им, несет ответственность и видит внутреннюю реализацию.
Как правило, граница software system = граница команды.
И вот нюанс... Software System — это НЕ bounded contexts, НЕ product domains, НЕ tribes или squads (организационные единицы Spotify модели).
Это конкретная система, которую нужно встроить в существующий ландшафт. В моем случае — микросервис чата в инфраструктуру компании.
🔻 Минималистичное проектирование начинается с системы, а не с кода. Это экономит время на согласование и избавляет от лишней документации.
Начиная с уровня системы, мы прорабатываем value для пользователей и связи между элементами. Только после этого можно спускаться вниз к деталям.
Иначе можно утонуть в обсуждении паттернов, когда еще не понятно что вообще строим.
Это первая статья серии "Проектирование". Дальше по порядку о каждом слое: контейнеры, компоненты, код.
Угадайте какой из них стоит генерировать, а не проектировать ручками? 😅
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#проектирование@UniArchitect