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