По Мартину нашему Фаулеру, жертвенная архитектура - архитектура, которую удаляют, если модель окажется успешной.
Так же, вопрос жертвенной архитектуры широко освещен в неплохой книге "Мифический человеко-месяц" Фреда Брукса.
Размазывать в статье не хочется, рассказывать о том, что рыбы вышли на сушу с жабрами, но им пришлось их откинуть за ненадобностью, не буду. Основная мысль в конце захайлайчена и если кто хочет сэкономить свое время, прошу сразу вниз ))
Что такое понятие жертвенной архитектуры?
При разработке какой-либо новой информационной системы, нужно быть готовым в любой момент "выбросить одну"
Это о том, что когда мы разрабатываем полностью новую ИС (информационную систему) или объемное решение, мы не знаем о количестве неизвестных неизвестных, которые нас ждут. С другой стороны, нашей задачей будет так же являться максимально быстрый вывод функционала в прод.
То есть мы не знаем до конца о том как наша система будет использоваться и какие критичные требования возникнут на первом этапе, при этом мы должны сделать её максимально быстро.
Тут есть два, наиболее часто встречающихся варианта:
- Мы быстро, насколько это возможно, клепаем MVP, ориентируясь только на требования MVP и у нас норм так получается. И наша система через год после MVP обретает кучу костылей и реализованного функционала по обходному пути. Что в свою очередь увеличивает техдолг до уровня сравнимого с повторным перепроектированием и разработкой нашего решения. У Брукса это называется прекрасным определением "Синдром второй системы".
- Мы очень долго проектируем, чуть ли не по Clear Room реализуем и у нас получается изящно-спроектированная система, которая побеждает не только известные известные, но известные неизвестные. Но реальная жизнь и тут может поставить нам подножку, относительно реальных кейсов использования нашей системы и требований к её уровню сервиса. Мы тратим время, растягивая ТТМ на то, чтобы привести нашу классную архитектуру к такому же классному целевому состоянию.
Третий вариант, который и является реализацией паттерна "жертвенная архитектура", это:
Осознанное понимание того, что архитектуру и реализацию нужно будет выкинуть и перейти на целевую, более дорогую в процессе рефакторинга. Мы не тратим много рессурсов на первый этап и в случае успеха сразу начинаем рефакторинг.
Какие примеры IRL можно привести:
- Discord, запустился на MongoDB и обернулся вокруг Cassandra по мере роста популярности
- Twitter разрабатывался на рубби на рельсах и по мере уже роста отказов слез с рубби.
Ну и таких примеров много.
Итак, что делать с жертвенной архитектурой?
Получается, что mvp-шнуцю архитектуру нам все равно придется выкинуть и что же?
Когда ты понимаешь цель того, что ты делаешь, становится проще это самое делать. Если ты понимаешь, что тебе придется отказаться от решения первого этапа до начала разработки и почему это произойдет, тебе будет легко поступить именно таким образом.
И по этому:
- Без сильной мотивации не стоит выходить за рамки требований MVP.
- При этом, стоит держать уме отраслевые и референтные модели, которые могут расширить требования.
- Проектируйте с оглядкой на замену, но без оверинженеринга.
- Облачные решения и паттерны разработки микросервисной архитектуры гарантированно снижают затраты на дальнейший рефакторинг, не увеличивая значительно затраты на разработку MVP и её сроки (в случае с enterprice решениями).
- Используйте интеграционные паттерны DDD и разделяйте контексты на ранних этапах. При этом установите правила (не границы, а правила их проведения) между доменами и контекстами.
