Теория проекта — за 15 минут

Почему сервисы разделены именно так? Где нельзя трогать? Как течёт информация? Эти знания живут в голове одного человека — и исчезают вместе с ним.

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

Выбери больПолучи модели и LLM-промтЗафикси артефакт
К фреймворкам
Начните с вашей проблемы
UNDRSYS-001
Не понимаем, что делает этот сервис
Понять ответственность сервиса, его границы и место в системе
UNDRSYS-002
Каждый разработчик объясняет систему по-разному
Сформировать общее инженерное понимание системы
UNDRSYS-003
Слишком сложно понять, как всё работает
Построить целостную карту системы
UNDRSYS-004
Непонятно, как течёт информация
Понять жизненный цикл данных и событий
UNDRSYS-005
Непонятно, где начинается и заканчивается ответственность сервиса
Определить границы системы и ответственности
UNDRSYS-006
Чтобы понять систему — нужно звать «того самого человека»
Сделать инженерное знание воспроизводимым
BOUND-001
Всё связано со всем
Уменьшить связность системы и понять реальные зависимости
BOUND-002
Не знаем, где разделять систему
Найти естественные границы системы и ответственности
BOUND-003
Хотим выделить сервис из монолита
Безопасно выделить сервис и снизить связанность
BOUND-004
Непонятно, что должно быть отдельным сервисом
Определить правильные границы сервисов
BOUND-005
Сервисы слишком сильно зависят друг от друга
Снизить связанность между сервисами
BOUND-006
Архитектура перестала масштабироваться
Найти узкие места архитектуры и подготовить систему к развитию
KNOW-001
Новый разработчик долго погружается в проект
Сделать устройство системы понятным для нового разработчика
KNOW-002
Никто не помнит, почему приняли это решение
Сохранить причины и контекст архитектурных решений
KNOW-003
Знания живут в головах людей
Материализовать инженерное понимание системы
KNOW-004
Ушёл разработчик — потеряли контекст
Сохранить контекст системы независимо от конкретных людей
KNOW-005
Архитектурные решения невозможно восстановить
Сделать архитектурную эволюцию системы прозрачной
KNOW-006
Документация не объясняет «почему»
Документировать не только структуру системы, но и причины решений
COMPLEX-001
Боимся менять код — непонятно что сломается
Сделать последствия изменений предсказуемыми
COMPLEX-002
Любое изменение тянет за собой ещё десять
Найти и уменьшить скрытую связанность системы
COMPLEX-003
Каждое изменение ломает что-то неожиданное
Выявить скрытые зависимости и побочные эффекты
COMPLEX-004
Система слишком связана
Снизить связанность и усилить границы системы
COMPLEX-005
Код стал слишком сложным для изменений
Упростить структуру системы и локализовать сложность
COMPLEX-006
Legacy страшно трогать
Безопасно исследовать и постепенно изменять legacy-систему