|
Professor Seleznov
|
Жил-был разработчик
Жил-был разработчик. Работал на Unity. Любил свою работу.
Разработчик любил архитектуру. Поэтому подключил DI-контейнер. Потом второй, потому что в первом не было ScriptableObject-биндингов. Потом третий, потому что во втором не работали async scope. Везде была фабрика фабрик, IServiceProvider, который под капотом резолвил IServiceProviderFactory, и пять способов сконфигурировать один и тот же InventoryService.
Разработчик любил чистый код. Поэтому развёл IInventoryService, IInventoryRepository, IInventoryFacade, InventoryDTO, InventoryMapper, InventoryValidator и InventoryQueryHandler. Семь классов, чтобы положить в инвентарь меч. Меч был один.
Разработчик любил тестируемость. Поэтому каждый класс брал в конструктор шесть интерфейсов. Когда геймдизайнер сказал «добавь параметр количества», пришлось пройти восемнадцать слоёв и обновить четыре регистрации контейнера.
Разработчик устал.
И написал свой фреймворк.
Это не статья про конкретные техники — они описаны в документации, ссылки в конце. Это статья про принципы, из которых эти техники следуют. И про то, почему именно такие принципы. Их пять.
Принцип 1. Технология должна окупаться
Сквозное правило отбора любой технологии во фреймворке: стоимость её внедрения и поддержания должна быть меньше профита, который она даёт.
Не «архитектурно правильно». Не «как делают в индустрии». Не «это best practice». Не «канонический паттерн». А конкретный, измеримый, чистый выигрыш на каждой задаче, в каждом use case.
Этот фильтр отсекает большую часть «канонической архитектурной красоты», которая в реальной разработке съедает больше, чем приносит. Семь интерфейсов вокруг одного меча - это и есть отрицательный баланс: стоимость поддержки растёт, а реального выигрыша от подменяемости семь раз нет, потому что меч - один.
Это банальный, кажется, принцип. Но именно он первым сдаётся в проектах, где «правильно» становится важнее «полезно». Vortex держит этот принцип явным правилом: технология попадает во фреймворк, только если её цена меньше того, что она даёт. Иначе - не попадает, даже если она «правильная».
Принцип 2. Учебник - это хорошо, но за костыли бьют не по учебнику
DI решает реальную задачу: «как класс получает зависимости в системе со сменными сервисами, разными scope’ами и несколькими instance’ами одного контракта». Это реальность backend-сервиса: сотни типов запросов, request / session / singleton scope’ы, реальная подмена реализаций под разные среды, разные тенанты.
Unity-клиент устроен иначе:
- 90% состояния глобально по природе (инвентарь, настройки, прогресс, текущий уровень)
- 90% подсистем стабильны на всё время игры (от Application.Start до Application.Quit)
- 90% инстанцирования идёт через инспектор, а не через код
Делать вид, что InventoryController - это сменный сервис, который можно перерегистрировать в рантайме - самообман. Он не сменный. Он один. На всю игру.
Vortex строится из того, что реально есть в Unity-клиенте: фиксированный набор подсистем, статическая структура зависимостей, инспектор как основной канал композиции, ScriptableObject как основной формат данных, MonoBehaviour как основная единица сцены. Не вокруг идеального мира с request scope’ами и interchangeable сервисами - а вокруг этой среды.
Если ваш рантайм устроен так же - отказ от backend-абстракций уберёт значительную часть бойлерплейта без потери возможностей. Если иначе (server-authoritative, headless, multi-tenancy) - вам нужен другой инструмент. Принцип 1 в действии.
Принцип 3. Верстка как программирование
В Unity-проекте большая часть production-работы - визуальная. Геймдизайнер собирает квест. Художник назначает анимации. Продюсер выставляет баланс. Левел-дизайнер расставляет триггеры. Они не пишут код. Они открывают инспектор.
Если архитектура заставляет каждое такое изменение проходить через программиста — она не подходит к Unity, как бы хороша ни была сама по себе. Не «плохая» - просто из другой среды, где content-pipeline идёт через JSON, миграции, deploy.
Vortex проектируется вокруг визуальной композиции. Цепочки логики квестов, конфиги подсистем, выбор драйверов, привязки UI, баланс - всё в инспекторе. Полиморфные [SerializeReference]-структуры, кастомные атрибуты для фильтрации и выбора, типизированные picker’ы по базам данных, drawer’ы для отображения long как даты или таймера - не дополнение, а основной production-канал.
Цена этого - жёсткая зависимость от Odin Inspector. ~$55 за seat, проприетарный, потенциально политически неприемлемый. Сознательный выбор: написать собственный аналог можно, но если Один уже есть в проекте - они подерутся. А делать библиотечную шизофрению на условных ключах - необоснованный мусор в коде. Принцип 1 фильтрует и эту цену.
Принцип 4. Структура должна быть видна
В DI-проекте dependency graph существует - но размазан между конструкторами, регистрациями, фабриками, scope’ами. Компилятор знает, что от чего зависит. Человек, открывший проект - нет, пока не оттрассирует bootstrap.
Vortex переносит структуру туда, где её видно глазами и где её проверяет компилятор:
- Слои разделены через asmdef. Core → Unity → Sdk → AppLocale, обратное направление запрещено физически. Это не соглашение, не review-правило, не строчка в стайлгайде - это компилятор отказывается линковать. Самая надёжная проверка из возможных.
- Подсистемы - статические шины с явными именами. Inventory, Database, QuestController. Кто чем пользуется - видно по using’ам и по asmdef-references. Не «угадай по [Inject]-параметрам, какой контейнер их резолвит».
- Сборка приложения - конфигурация в ScriptableObject. Не services.AddSingleton<IFoo, FooImpl>() в bootstrap-классе, а список драйверов и пакетов в инспекторе. «Из чего состоит приложение» - это галочки в Project Settings, а не код в Composition Root, который надо читать.
Цена: dependency graph теперь не в конструкторах класса, а в asmdef-references и в коде. Новичку нужна карта шин. Без неё утонет. Не утверждаем, что цена маленькая, но и огромной - не назвать.
Профит: компилятор проверяет архитектуру. Структура видна на уровне файлов и папок. Чтобы понять состав приложения - не надо запускать debug-сессию.
Принцип 5. Каждому шурупу - свой молоток
Есть старый анекдот про бюрократов которые требуют чтобы мироздание было приведено к бумажным стандартам, но ни в коем случае наоборот... Ничего не напоминает? А если посмотреть на архитектурно чистый DI в Unity проекте?
Vortex - специализированный инструмент. Не серебряная пуля. Не «правильная архитектура для всего».
Он эффективен, когда:
- рантайм - Unity-клиент с фиксированной структурой подсистем
- production-канал включает дизайнеров и художников, работающих через инспектор
- команда готова разделить дисциплину архитектурного канона
- Odin Inspector допустим как зависимость
Он неэффективен или вреден, когда:
- рантайм - backend, headless, server-authoritative с in-process multi-tenancy
- проект - микропрототип на 1–2 экрана, не окупающий оверхед инфраструктуры
- compile-time safety важнее workflow-скорости (нет shared review-дисциплины)
- Odin Inspector нельзя по политике, лицензии или убеждениям
- код должен работать вне Unity (CLI, WebAssembly, headless-симуляция)
Это не маркетинговая оговорка ради приличия. Если ваш профиль попадает в зону «не для этого» - Vortex даст результат хуже, чем DI или любой другой подходящий инструмент. Используйте то, что соответствует вашему рантайму, а не то, что красивее звучит на конференции.
Это принцип 2 в обратную сторону: инструмент подбирается под среду, а не среда переделывается под инструмент. Если у среды и инструмента разная природа - на стыке всегда будет натирать, и натирать будет именно ту команду, которая взяла «модно».
Что дальше
Конкретные техники - owner-key для capability-based мутации, реактивные значения, логические цепочки, статические шины подсистем, layered asmdef, ScriptableObject-композиция, драйверная модель - это следствия принципов, а не их источник. Каждое решение во фреймворке проходит фильтр принципа 1. Каждое объяснимо через один из остальных четырёх.
Если принципы зашли - в документации это разобрано подробно по топикам:
Если не зашли - Vortex не для вас, и это нормально. Принцип 5.
Эпилог
Жил-был разработчик. Задолбался от DI и итальянской кухни. Построил фреймворк, в котором принципы важнее догматов.
Если у вас в проекте тоже стоят шесть слоёв над тем, чтобы положить меч в инвентарь — возможно, проблема не в том, что слоёв мало. Возможно, вы заимствовали архитектуру у тех, чей рантайм устроен иначе.-Источник
|
