ПРОЕКТИРОВАНИЕ: С ЧЕГО НАЧИНАТЬ Устроился в 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