Комментарии 20
Что-то я запутался:
Это вообще как? В первом предложении OPUS описывается как приложение, которое отвечает по сути за мастер-данные. Во втором, в нем уже есть наличие. А так как остаток товара является результатом товародвижения, то получается что в нем и все движение есть? Или есть какое-то третье приложение, которое ведет движение, и в какие-то моменты передает в этот OPUS остатки? Но как тогда обеспечивается транзакционность и актуальность данных?
Про MoVe — вообще не понял зачем оно? Есть некий AEM, который фронт, но чекаут идет в MoVe — это как?
В привычной для меня картине, есть фронт — который отвечает за обслуживание покупателей (и может работать даже, если бэк лежит). И бэк, который отвечает за все остальное (товародвижение, ценообразование и т.д.). В частности, из бэка в фронт идут цены и прочая информация, а в обратную сторону данные о продажах.
за ним в беке было два больших приложения: OPUS и MoVe. Первое — это база данных свойств каждого товара (от габаритов до описания)
Но вернёмся к OPUS. Так как система хранит актуальную информацию по наличию, характеристикам, транзакциям и прочему, мы стучали к ней по любому поводу.
Это вообще как? В первом предложении OPUS описывается как приложение, которое отвечает по сути за мастер-данные. Во втором, в нем уже есть наличие. А так как остаток товара является результатом товародвижения, то получается что в нем и все движение есть? Или есть какое-то третье приложение, которое ведет движение, и в какие-то моменты передает в этот OPUS остатки? Но как тогда обеспечивается транзакционность и актуальность данных?
Про MoVe — вообще не понял зачем оно? Есть некий AEM, который фронт, но чекаут идет в MoVe — это как?
В привычной для меня картине, есть фронт — который отвечает за обслуживание покупателей (и может работать даже, если бэк лежит). И бэк, который отвечает за все остальное (товародвижение, ценообразование и т.д.). В частности, из бэка в фронт идут цены и прочая информация, а в обратную сторону данные о продажах.
Если быть точным, OPUS — это система для подготовки контента, в которой находятся все характеристики товаров. Для фронта она используется как мастер данные, поэтому в статье это было сильно упрощено. Изменение остатков производится в другой системе, события из которой приходят через очередь. Есть отличное видео по тому, как это всё устроено с прошлого Хайлоада — Распил монолита в Леруа Мерлен.
Если упрощать, то действительно можно рассматривать систему как фронт и бек. Только в данном случае мы имеем дело как с множеством фронтов (мобилка, веб, киоски в магазине, приложение для сотрудников), так и с множеством беков (опус, туннель заказа). Больше об этом в нашей предыдущей статье. Различные домены: доставка, коммуникация с пользователями, платежный домен. Соответственно, MoVe — это версия туннеля заказа, сделанная французами, которую мы и перепилили.
ValeryLaptev можешь, пожалуйста, посмотреть фактуру?
Если упрощать, то действительно можно рассматривать систему как фронт и бек. Только в данном случае мы имеем дело как с множеством фронтов (мобилка, веб, киоски в магазине, приложение для сотрудников), так и с множеством беков (опус, туннель заказа). Больше об этом в нашей предыдущей статье. Различные домены: доставка, коммуникация с пользователями, платежный домен. Соответственно, MoVe — это версия туннеля заказа, сделанная французами, которую мы и перепилили.
ValeryLaptev можешь, пожалуйста, посмотреть фактуру?
Если честно, то в той статье ни слова ни про туннелирование заказов, ни про OPUS, ни про MOVE. Там вообще конкретики очень мало. Видео тоже не очень удобный формат для того, чтобы разбираться в сути.
Не обижайтесь, но в ваших статьях слишком много воды. Все сводится к тому, что микросервисы — это круто, эджайл — это круто, много команд разработчиков и коммуникаций — это круто и т.д.
Просто у меня перед глазами несколько компаний, где тоже работают тысячи сотрудников, c монолитом, который поддерживают и дорабатывают 10 человек (это инсорс + аутсорс). Если им предложить нанять 200 человек (то есть тратить по 500К$ в месяц), то они просто покрутят пальцем у виска.
По вашим статьям у меня создается впечатление, что 200 человек нужны для того, чтобы создавать абсолютно бессмысленные сервисы, цель которых взаимодействовать ради взаимодействия. Я вполне допускаю, что заблуждаюсь. И поэтому спрашиваю про назначения конкретных приложений/служб, чтобы понять какое преимущество это дает.
Я понимаю, что вам досталось «говно мамонта» в виде устаревшей во всех смыслах системы. Но с таким же успехом можно было сделать с нуля монолит (или купить какой-то современный монолит с исходным кодом и начать его допиливать под свои нужды), постепенно на него мигрируя со старой системы.
Хорошо было бы, чтобы вы описали сверху всю архитектуру. Какие есть приложения, какие функции они выполняют и как взаимодействуют друг с другом.
Не обижайтесь, но в ваших статьях слишком много воды. Все сводится к тому, что микросервисы — это круто, эджайл — это круто, много команд разработчиков и коммуникаций — это круто и т.д.
Просто у меня перед глазами несколько компаний, где тоже работают тысячи сотрудников, c монолитом, который поддерживают и дорабатывают 10 человек (это инсорс + аутсорс). Если им предложить нанять 200 человек (то есть тратить по 500К$ в месяц), то они просто покрутят пальцем у виска.
По вашим статьям у меня создается впечатление, что 200 человек нужны для того, чтобы создавать абсолютно бессмысленные сервисы, цель которых взаимодействовать ради взаимодействия. Я вполне допускаю, что заблуждаюсь. И поэтому спрашиваю про назначения конкретных приложений/служб, чтобы понять какое преимущество это дает.
Я понимаю, что вам досталось «говно мамонта» в виде устаревшей во всех смыслах системы. Но с таким же успехом можно было сделать с нуля монолит (или купить какой-то современный монолит с исходным кодом и начать его допиливать под свои нужды), постепенно на него мигрируя со старой системы.
Хорошо было бы, чтобы вы описали сверху всю архитектуру. Какие есть приложения, какие функции они выполняют и как взаимодействуют друг с другом.
Конечно, сейчас мы только начали постепенно выкладывать статьи. Дальше — будет и про архитектуру, и больше сугубо технических статей. В одной статье это просто невозможно описать.
В двух словах, монолит — это то не наша история. О плюсах и минусах можно спорить долго, для себя мы выбрали микросервисный путь. Можно почитать Криса Ричардсона, например. Сейчас мы по большей части и переносим функционал со старых систем в новые. О причинах как раз и было описано в предыдущей статье. И, конечно, мы знаем о многих ошибках или недоработках, о которых пишут в комментариях. Мы работаем, у нас есть приоритеты. Некоторые ошибки просто невозможно исправить в текущих приложениях, мы их устраним в новых.
И, конечно, мы не производим приложения ради приложений. Бизнес ориентируется исключительно на потребности наших клиентов (как внешних, так и внутренних). И поэтому наши команды разработки все чаще выезжают, к примеру, в магазины, чтобы видеть, как наши приложения работают в боевых условиях, и моментально получать актуальную обратную связь.
В двух словах, монолит — это то не наша история. О плюсах и минусах можно спорить долго, для себя мы выбрали микросервисный путь. Можно почитать Криса Ричардсона, например. Сейчас мы по большей части и переносим функционал со старых систем в новые. О причинах как раз и было описано в предыдущей статье. И, конечно, мы знаем о многих ошибках или недоработках, о которых пишут в комментариях. Мы работаем, у нас есть приоритеты. Некоторые ошибки просто невозможно исправить в текущих приложениях, мы их устраним в новых.
И, конечно, мы не производим приложения ради приложений. Бизнес ориентируется исключительно на потребности наших клиентов (как внешних, так и внутренних). И поэтому наши команды разработки все чаще выезжают, к примеру, в магазины, чтобы видеть, как наши приложения работают в боевых условиях, и моментально получать актуальную обратную связь.
Хорошо, а в чем принципиальное преимущество микросервисной архитектуры в вашем случае? В чем разница будут, например, Java классы взаимодействовать друг с другом в монолите (одной виртуальной машине) путем стандартных Java-вызовов, или «микросервисы» через REST-API?
Точно также можно было при желании делать бы фичи-команды, повторно используемый код и т.д.
Точно также можно было при желании делать бы фичи-команды, повторно используемый код и т.д.
Как красиво, но посмотрим, что видит обычный покупатель (например, в Москве):
на сайте указано количество «наличие» штук 10, а в магазине — товара нет.
А что Вы хотели? Звоните в конкретный магазин и уточняйте — ответ, который слышал не раз.
Что же там такое наавтоматизировали?
Может я такой не везучий, но подобные ситуации свели к тому, что я не доверяю уже системе наличия товара.
Про продавцов-недоконсультантов это наверное не к вам :)
Простите, наболело.
А еще у вас забавные «АКСЕССУАРЫ ДЛЯ ГАЗОНОКОСИЛОК» — leroymerlin.ru/product/akkumulyator-mobilnyy-2-6-ach-18594193
на сайте указано количество «наличие» штук 10, а в магазине — товара нет.
А что Вы хотели? Звоните в конкретный магазин и уточняйте — ответ, который слышал не раз.
Что же там такое наавтоматизировали?
Может я такой не везучий, но подобные ситуации свели к тому, что я не доверяю уже системе наличия товара.
Про продавцов-недоконсультантов это наверное не к вам :)
Простите, наболело.
А еще у вас забавные «АКСЕССУАРЫ ДЛЯ ГАЗОНОКОСИЛОК» — leroymerlin.ru/product/akkumulyator-mobilnyy-2-6-ach-18594193
В копилку недовольств можно отнести некачественный поиск. И это очень большая проблема именно бизнеса. Не знаю уникальный кейс или нет, но в какой-то момент осознал, что проще что-то погуглить, перейти на сайт ЛМ и там уже в корзинку добавить или что-то ещё сделать в карточке товара. С одной стороны эта проблема юзабилити, но в какой-то момент из поисковой выдачи внезапно обнаружил, что у конкурента есть те же позиции на более выгодных условиях.
Или ещё прекраснее — по данным продавца в зале товар есть (порядка сотни штук), а приходишь на склад и пытаешься найти — нету.
Хватает работников склада — не находим.
Хватаем продавца — не находим. Час времени потрачен безрезультатно.
В этом плане удобнее оформлять самовывоз (правда, приходится заранее) — в этом случае вопросы поиска фрагментов заказа ложатся на сотрудников Леруа.
Несмотря на то, что раньше корректность стоков не была нашим коньком, в последнее время ситуация с этим должна была улучшиться. А косилки поправим, спасибо.
А для чего у вас Навижин?
Может у вас все и хорошо с точки зрения всяких метрик, подходов и концепций. И даже инструменты, возможно, подходящие. Не суть.
Но вот когда личный кабинет постоянно разлогинивает тебя. И в него не всегда (или всегда не) получается зайти с первого-второго раза и приходится настаивать.
Или когда список товаров из отложенных или корзины — просто пропадает и надо все собирать заново.
Про чудо поиск уже написали. И про «наличие» в магазине.
И ещё оплата интернет заказа часто срывается и надо повторять.
Вот с этими информационными «технологиями» и сталкивается обычный покупатель.
«Повторите последнее действие...»
Сам магазин нравится. Ассортиментом и количеством точек присутствия. Но сайт — жуть жуткая по удобству использования
Мы, в целом, знаем про большое количество подобных задач, и они лежат в бэклоге. Другое дело, что нужно больше людей, которых мы как раз набираем, чтобы российский ИТ-отдел мог всё сделать почти идеально. Собственно, если вы знаете кого, кто может взяться и поправить это, либо помочь чем-то ещё, присылайте резюме на почту Anna.Bocharova@leroymerlin.ru
Классный проект, очень интересный.
Спасибо, что поделились опытом — такие примеры вдохновляют
Дважды прочитал — Как мы РАЗВАЛИЛИ ИТ в «Леруа Мерлен»
Видимо сказывается негатив на текущем месте работы
Видимо сказывается негатив на текущем месте работы
Ребята, у вас так «всё сложно», а я ещё удивлялся, почему у меня в мобильном приложении указан один номер карты и пустая история покупок, а при входе с теми же учетными данными на сайте другой номер карты и есть история покупок. И уже несколько месяцев в моей истории покупок добавляются чужие покупки. Год не могу решить эту проблему через обращения на сайте и через визиты в магазин. Для меня, как вашего клиента, сервисная карта и интернет-магазин не взлетели, продолжаю хранить чеки и выбирать товары между стеллажей. Может, надо в том числе внимательнее реагировать на обращения?
Когда статья про умные вещи, а на деле — заказ на сайте не работает — чтобы узнать статус заказа, надо звонить в колл-центр. Коммон ребята, вы типовой функционал-то хотя бы доделайте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы развивали ИТ в «Леруа Мерлен»: пересборка двигателя на ходу