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