roman72

Статья великолепная, предложенная технология мне вполне импонирует,
частично то или иное мне приходилось делать или хотя бы продумывать.

Но в целом, у меня сложилось впечатление, что у автора эта технология используется для разработки "коротких" функций, которые буквально за 1 рабочий день решаемы.
Если задача долгосрочная (недели месяцы), например встройка сложного алгоритма, то работа команды по такой технологии будет сбоить. Например, из-за гарантированного изменения мастер ветки и окружения за время разработки "длинной" функции".
И такую технологию будет трудно воспроизвести команде-владельцу конфигурации (команде заказчика) - ведь тогда надо будет, чтобы технологию соблюдали все нанятые на проект франчи и свободные фримены - как по началу проекта, так и просле его завершения, так и при дальнейших проектах развития конфы.

ЗЫ Касаемо изобретённого термина "лысая" конфигурация - ну зачем?
Был же хороший термин "конфигурация поставщика" - это же оно и есть.
А "лысое" оно лишь в течение первых 5 минут после создания конфы.

(3) Статья отличная, а ваш коммент к ней ещё лучше

На такого Путина я подписываюсь!

(24) Так и Кафка с кроликом это же самое могут. Нет?

(21) Бесшовная объявлена для "любой" конфигурации, для любой пары конфигураций.
Да, с ЕРП часто бесшовку используют. Но она не только для ЕРП работает.

(20)
Это не на мой вопрос ответ. Ответ там про частный случай и функционал технологии.
А я спросил про принципиальные отличия технологии.
То что кафке может что-то понадобиться допилить, так и шине допиливать придётся и приходится.

Есть ещё один вопрос.
Вот такой момент - как шина увязывается с бешовной интеграцией 1С (это у них отдельная технология и у неё много преимуществ).
Как принимаете решение гнать объект через шину или через бесшовку, по каким критериям?

Ждёмс продолжения цикла.
И отдельный вопрос на сейчас:
Хотелось бы увидеть изложение конкретного технологического преимущества шины как технологии перед брокерами сообщений. Т.е. что может только шина, но не могут кролик и кафка.

Не понял - RPA это значит Vanessa в СППР победит всех, всё и вся?

(7) Никто речь не ведёт о том чтобы избавиться от программистов через автоматизацию описания архитектуры.
Архитектура касается не только программного кода, но и иных операций,
например:
нужно описать интеграцию между несколькими системами, определить список интгерируемых данных, направления обмена, нагрузк уна каналы обмена.
Кода ещё никакого нет, а архитектура уже есть. И её описание весьма трудоёмко. Поэтому нужна автоматизация уже здесь.

А что касается архитектуры непосредстенно ПО - программистам нужен внятный и понятный вектор "как работать, в какую сторону писать код, как и что связано на функицональном уровне в зависимости от кода" - архитектура как такой вектор весьма необходима.