С утра созвонился со знакомым Архитектором, который купил курс. — 5 августа 2026 г. в 09:34:35.227
С утра созвонился со знакомым Архитектором, который купил курс. Звонил, чтобы задать один вопрос 👇 «Я давно тебя знаю, ты крутой специалист. Зачем тебе вообще идти на курс?» И он ответил: «Я архитектор на бумаге. А в чем на самом деле заключается моя работа, я не очень хорошо представляю» Человек работает архитектором в крупном интеграторе, получает хорошую зарплату, решает серьезные задачи. Но у него нет главного — системы, на которую опираться и с которой сверять собственные решения. Словарь архитектора должен состоять из таких вопросов: — как правильно определить границы системы — как декомпозировать систему на модули — как разделить ответственности между объектами — как выстроить зависимости в коде Это язык настоящего архитектора. Но в мире 1С многие архитекторы не понимают смысла этих вопросов. Не говоря уже о том, чтобы использовать их в работе. Мой знакомый знает про слои. Понимает общий посыл: систему нужно разделять, бизнес-логику нельзя размазывать по формам и общим модулям, зависимости нужно контролировать. Но дальше начинаются вопросы. 👉 Как прийти к этому разделению в реальной задаче? 👉 На что именно декомпозировать систему? 👉 Где должна пройти граница? 👉 Чем Application отличается от Domain? 👉 Зачем нужны контроллеры, репозитории и дополнительные слои? С UI более-менее понятно: интерфейс отделяем от остальной логики. Условно есть UI и есть все остальное. А дальше понимание заканчивается. Он пишет код, распределяет его по общим модулям, обработкам и объектам 1С. Код работает. Задача решена. Но остается вопрос: «Насколько хорошо все это спроектировано? Я действительно правильно разделил ответственности или просто разложил код так, как мне сейчас показалось логичным?» И главное — с чем сверяться? 👉 Нет понятных критериев 👉 Нет системы принятия решений 👉 Нет уверенности, почему одно архитектурное решение лучше другого Решению этой проблемы посвящен курс. Задача — не изучить набор слоев, паттернов и схем, а научиться проектировать системы: 👉 от пользовательского сценария — к границам системы 👉 от границ — к модулям 👉 от модулей — к ответственности объектов 👉 от ответственности — к доменной модели и зависимостям 👉 а затем встроить все это в типовое решение 1С Чтобы на вопрос: «Почему система спроектирована именно так?» отвечать не: «Мне показалось, что так логичнее». А: «Потому что вот границы. Вот ответственности. Вот зависимости. И я понимаю, почему они устроены именно так» Мне кажется, именно с этого момента архитектор перестает быть архитектором на бумаге. Что думаете?