Comments 2
А можно осветить тему того, как избежать хаоса при платформенном строении сервисов?
Хочется понимать, какие инструменты можно использовать и как делать факт-чекинг решений, чтобы избежать задвоений
В моей практике это всегда ложится на плечи архитекторов и некоторой "антитунельной" службы. Конечно нужен реестр сервисов в специализированных каталогах или просто в Confluence, в котором будет описана существующая функциональность. Однако часто в каких-то моментах создаваемый сервис будет похож на уже существующие и вот это принятие решения действительно ли это дубль или пересечение обосновано автоматизировать полностью невозможно.
В остальном по инструментам для украшения хаоса: стандартизация (как в крупную клетку на всю компанию, так и отдельные прикладные руководства), архитектурные ревью, воркшопы (для информирования о существующем функционале) и стартовые шаблоны для типовых сервисов
Заметки теоретика. Откуда растут платформы: «Снизу» vs «Сверху» — архитектура выбора