Архитектура дизайн-системы для нескольких продуктов

[zahmTOD]

С увеличением количества обслуживаемых продуктов наша дизайн-система начала разваливаться. Вырос порог входа для дизайнеров и работать с ней стало труднее. В статье расскажу как мы перешли на модульную архитектуру и не растеряли консистентность.

Oladislav, представтесь пожалуйста.

[ramil_trinion]

Примеров нет. Рассказывают вроде про дизайн, а дизайн иллюстраций небрежный.

[tvant]

Найденное решение — это комбинация из первой и последней схемы стартовой иллюстрации в статье. Надо же — велосипедостроители! Такая схема использовалась со времен эпохи UNIX. Всё очень просто и, можно сказать, стандартно. Есть базовая библиотека на всю инфраструктуру (систему), плюс каждый проект (продукт) имеет свою специфическую библиотеку.

[tnc4401]

Автор, хорош, проблемы раскрыл. А найденное решение спорное. Предполагаю что в разработке все хорошо, а в поддержке на протяжении 2 лет будет не очень. Ведь со временем продукты и их собственные библиотеки будут все больше и больше расходиться. Синхронизировать и прийти к общему результату, или особенно провести полный редизайн всей системы — будет невероятной болью.

Я намучался и перешел к следующему подходу:

Библиотека слишком большая. Работая над фичей, дизайнер абстрагируется от перегруженной и сложной библиотеки. Он собирает и детачит компоненты прямо в рабочем файле, надеясь, что однажды они просто перетекут в библиотеку и станут "легальными". Чтож, удачи.

То есть рыцари круглого стола собираются и синхронизируют главную библиотеку продуктов на регулярной основе, раз в 1-2 недели.

А иллюстрации и объяснение отличное (смысл понятен мгновенно, и это самое важное)