Я не начинаю IT-аудит с перечня программ: сначала смотрю, где решение застревает
IT-аудит полезнее начинать с регулярного решения бизнеса: так быстрее видны ручные обходы, спорные данные и места без владельца.
Читать статью →архитектурные решения — Алексей Журинов
Рубрики
Популярные метки
Я задаю нагрузочный сценарий языком рабочего дня, а не количеством запросов в секунду
Почему нагрузку системы полезно описывать через критичный рабочий день: роли, действия, порог ожидания, зависимости и безопасную деградацию.
Читать статью →Я определяю границы сервисов по тому, кто меняет правило
Почему границы сервисов стоит определять по владельцу и жизни бизнес-правила: как избежать дробления ради схемы и сделать изменения в системе управляемыми.
Читать статью →Я делаю журнал изменений частью архитектуры, когда система влияет на деньги и обязательства
Почему журнал изменений нужен архитектуре: какие факты сохранить о важном решении, как не превратить историю в контроль людей и быстрее вернуть систему в безопасное состояние.
Читать статью →Я сначала фиксирую правило, а потом выбираю технологию для архитектуры
Как принимать архитектурные решения от бизнес-правил: назначить владельца, определить границы данных, предусмотреть безопасное поведение при сбое и путь назад.
Читать статью →Я не добавляю сервис в архитектуру, пока не знаю, что будет без него
Как проверить новую сервисную зависимость в архитектуре: пройти маршрут пользователя, определить безопасное поведение при сбое и сохранить возможность выйти из решения.
Читать статью →Я выбираю архитектурное решение по тому, как из него можно выйти
Как оценить архитектурное решение через обратимость: увидеть точку невозврата, защитить данные, ограничить первый шаг и сохранить возможность менять курс без пожара.
Читать статью →Я не прошу оценку разработки, пока не понимаю цену неверного решения
Почему оценка разработки начинается не с часов: как увидеть риск неверного решения, зафиксировать условия и разбить работу на проверяемые этапы.
Читать статью →Временное решение становится проблемой не в день запуска, а в день роста
Почему временные таблицы, ручные правила и обходные пути незаметно становятся критической частью бизнеса — и как вернуть им управляемость.
Читать статью →Архитектурный выбор без владельца превращает проект в спор
Техническое решение становится дорогим спором, когда никто не отвечает за его критерии, границы и последствия. Я разбираю, как назначить владельца архитектурного выбора.
Читать статью →