Какое-то странное выступление. Не тратьте время. Несёт какой-то бред. Структуры выступления нет. Может быть я тупой? Но я правда не понял чего выступающий собственно хотел до нас донести. 😂
Все верно, бред он и есть бред, но выросло новое поколение, которое не видело лоскутной автоматизации с торговлей информацией внутри компании. А ИТшники будут париться не с обновлением системы, а с написанием многосторонней интеграции, с подключением узкоспециализированных специалистов, которых на рынке вообще нет
ИМХО, выступающий пытался донести до нас идею, что микро сервисы это стильно, модно, молодежно (с), я всякие ЕРП и прочие динозавры - фу такими быть. Но, с моей точки зрения, у него получилось лишь показать что такого ценного специалиста как он надо засылать автоматизатором к своим злейшим конкурентам. И тогда вопрос с ними будет решен.
С точки зрения бухгалтерии, как раз какой iРhone разницы никакой нет. Это просто денежный ресурс на остатках. А вот для складского учета да разница есть, там каждая отдельная модель учитывается отдельно. У нас почему то бухгалтерию приравнивают к любому учету на предприятии.
И термин "организация цифрового учета" (будто сегодня есть какой-то нецифровой учет)) и тезис нехватки программистов неверный с точки зрения и DDD и слабой связанности. Крупная система это узкое горлышко и организационный монолит. Про то и речь в ролике, но поймет это лишь управленец.
С чего это "для бухгалтерии важен только артикул"? И про разные счета для продаж и бухгалтерии тоже какая то дичь. Свойства их могут быть для продаж и бухгалтерии разными и т.д. Интересно. Автор работал реально бухгалтером? Вообще, очень сомнительные и путанные объяснения предлагаемых идей. В общем, я не увидел чего то нового, интересного, заявленного в названии.
Примеры как минимум странные. Для бухгалтерии и склада используется товарная позиция «iphone 13 белый 256 gb», для маркетинга настраиваться соответствие по нужным им правилам, с учетом множества вариаций. Решение в использовании шины, но для шины разве не нужно определять жесткие алгоритмы сопоставления? Разве не возникают аналогичные концептуальные проблемы? Как шина защитит от организационных проблема с занесением дублей контрагентов? Тема интересная, хотелось бы услышать более развернутое решение.
В какой системе будет настраиваться соответствие? Кто будет продуктоунер функционала соответствия? самой системы? Шина - это лишь инструмент слабо связанного взаимодействия. Коннектор шины - это микросервис, который берет из сервиса и кладет в общий контекст (таблицу и/или брокер, в зависимости от типа сущности). Суть то в том что твой сервис начинает отвечать только за свой ЦКП, не должен дублировать другие сущности, не должен содержать не твоих данных и только один продукт оунер должен за него отвечать. Иначе зона ответственности размыта. И вопрос реализации шин вторичен - шина это всего лишь набор микросервисов которые кладут в общедоступные (сервисам) хранилища информации и микросервисов, которые забирают из общего контекста в сервис.
@@andrey_putin ыыы странное видео, есть теория баз данных фундамент всех ваших продуктов с хранением занесением получением информации)), давайте посмотрим на идею видео ролика Битрикс 24, 1с Бухгалтерия, Мой Склад, АСУП Завод и куча виджетов + куча доработок и все данные сопоставляем еще через одну надстройку. Итог такого роутера, та же монолитная система из кучи продуктов от разных разработчиков гениально. Кривая структура БД, цена новых связей данных космос и поправить 1 микро сервис = поправить 100 микро сервисов так себе идейка.
@@utandr Ок,спасибо.Я к тому,что при изменении версии этого продукта ( ESB) не нужно менять интеграционный модуль,который ты на схеме нарисовал? Или такой модуль пишется только когда связь точка-точка (PIM-CRM на диаграмме) ?
@@cocojama1 если менять приходится - это принцип сильной связанности и это монолит. Если менять не приходится, это принцип слабой связанности и SOA. Как сделать так чтобы не приходилось менять - подробнее смотрите про ESB
Если ERP не работает, "вы просто не умеете их готовить" 😁
Скорее, что работает вместо ERP?
Какое-то странное выступление. Не тратьте время. Несёт какой-то бред. Структуры выступления нет.
Может быть я тупой? Но я правда не понял чего выступающий собственно хотел до нас донести. 😂
Жаль, что нам не удалось донести концепт слабой связанности
Все верно, бред он и есть бред, но выросло новое поколение, которое не видело лоскутной автоматизации с торговлей информацией внутри компании. А ИТшники будут париться не с обновлением системы, а с написанием многосторонней интеграции, с подключением узкоспециализированных специалистов, которых на рынке вообще нет
ИМХО, выступающий пытался донести до нас идею, что микро сервисы это стильно, модно, молодежно (с), я всякие ЕРП и прочие динозавры - фу такими быть. Но, с моей точки зрения, у него получилось лишь показать что такого ценного специалиста как он надо засылать автоматизатором к своим злейшим конкурентам. И тогда вопрос с ними будет решен.
С точки зрения бухгалтерии, как раз какой iРhone разницы никакой нет. Это просто денежный ресурс на остатках. А вот для складского учета да разница есть, там каждая отдельная модель учитывается отдельно. У нас почему то бухгалтерию приравнивают к любому учету на предприятии.
На видео спутаны вместе концептуальные проблемы организации цифрового учета и просто то, что банально нехватает программистов для решения всех задач))
И термин "организация цифрового учета" (будто сегодня есть какой-то нецифровой учет))
и тезис нехватки программистов неверный с точки зрения и DDD и слабой связанности.
Крупная система это узкое горлышко и организационный монолит. Про то и речь в ролике, но поймет это лишь управленец.
Про альтернативу так и не сказали
Попытался описать на конференции в ruclips.net/video/VAprBL65OdY/видео.html
Было интересно. Вот только концовка смазана, её фактически нет.
С чего это "для бухгалтерии важен только артикул"?
И про разные счета для продаж и бухгалтерии тоже какая то дичь. Свойства их могут быть для продаж и бухгалтерии разными и т.д.
Интересно. Автор работал реально бухгалтером? Вообще, очень сомнительные и путанные объяснения предлагаемых идей.
В общем, я не увидел чего то нового, интересного, заявленного в названии.
Да, у меня диплом спецкурсов (профподготовки) бухгалтерского учета в России и отдельно в UNO GAAP.
@@andrey-putin-ktteam Понятно. А бухгалтером, реально, доводилось работать?
Примеры как минимум странные. Для бухгалтерии и склада используется товарная позиция «iphone 13 белый 256 gb», для маркетинга настраиваться соответствие по нужным им правилам, с учетом множества вариаций.
Решение в использовании шины, но для шины разве не нужно определять жесткие алгоритмы сопоставления? Разве не возникают аналогичные концептуальные проблемы? Как шина защитит от организационных проблема с занесением дублей контрагентов?
Тема интересная, хотелось бы услышать более развернутое решение.
В какой системе будет настраиваться соответствие? Кто будет продуктоунер функционала соответствия? самой системы?
Шина - это лишь инструмент слабо связанного взаимодействия.
Коннектор шины - это микросервис, который берет из сервиса и кладет в общий контекст (таблицу и/или брокер, в зависимости от типа сущности). Суть то в том что твой сервис начинает отвечать только за свой ЦКП, не должен дублировать другие сущности, не должен содержать не твоих данных и только один продукт оунер должен за него отвечать. Иначе зона ответственности размыта.
И вопрос реализации шин вторичен - шина это всего лишь набор микросервисов которые кладут в общедоступные (сервисам) хранилища информации и микросервисов, которые забирают из общего контекста в сервис.
@@andrey_putin ыыы странное видео, есть теория баз данных фундамент всех ваших продуктов с хранением занесением получением информации)), давайте посмотрим на идею видео ролика Битрикс 24, 1с Бухгалтерия, Мой Склад, АСУП Завод и куча виджетов + куча доработок и все данные сопоставляем еще через одну надстройку. Итог такого роутера, та же монолитная система из кучи продуктов от разных разработчиков гениально. Кривая структура БД, цена новых связей данных космос и поправить 1 микро сервис = поправить 100 микро сервисов так себе идейка.
Я новичок в тематике. Подскажите,а ESB это какой-то отдельный программный продукт?
Это класс продуктов. 1С ERP, SAP ERP (BO, Hana), Microsoft Dynamics и тп
@@utandr Ок,спасибо.Я к тому,что при изменении версии этого продукта ( ESB) не нужно менять интеграционный модуль,который ты на схеме нарисовал? Или такой модуль пишется только когда связь точка-точка (PIM-CRM на диаграмме) ?
@@cocojama1 если менять приходится - это принцип сильной связанности и это монолит. Если менять не приходится, это принцип слабой связанности и SOA. Как сделать так чтобы не приходилось менять - подробнее смотрите про ESB
Вам тут снова вывалили порцию бреда. Тупо погуглите.
Выздоравливайте!😂
спасибо, здоровы )
Очень точное описание 👍
бред полный ..... Понимаю когда отделили ЗУП и 1 С Бухгалтерия .... но все остальное очень черевато - фин.результат не получиш корректно.....
нихера не понятно
У вас получилось натянуть сову на глобус...
Мне кажется и это у него не получилось.😂
Простая глупость, иначе это видео не назовешь 😂