Pull to refresh

Comments 10

Если вы тоже сталкиваетесь с задачами интеграции 1С и e-commerce или думаете, как оптимизировать обмен данными в своем проекте, пишите нам.

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

Интересная статья, спасибо! Cразу возник практический вопрос: насколько сложно внедрить подобные практики (например, регулярные выражения для валидации) в уже существующий большой легаси-проект, где кодовая база не всегда идеальна? С чего лучше начать, чтобы не сломать то, что уже работает, и не вызвать сопротивление у команды?

Спасибо за вопрос! В легаси-проектах главное — не пытаться внедрить всё сразу. Лучше идти маленькими шагами: выбрать один понятный кейс, обернуть его простыми тестами и добавить «мягкую» валидацию (сначала просто логировать ошибки, не ломая процесс).

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

на практике - проблема в том что екомер уж боьнот разеый.

Редко удается отобразить данные как есть.

Да, это так. В e-commerce почти никогда не получается отобразить данные «как есть». Почти всегда нужна прослойка, которая преобразует их под логику сайта и ожидания пользователей - маппинг, адаптеры, иногда даже своя модель каталога.

UFO landed and left these words here

Если объект ссылается на то, чего ещё нет, мы его не теряем, а сохраняем «в ожидании». Когда связанный объект приезжает, система достраивает связь. Если он так и не появился, то отмечаем ошибку и можно повторно запросить данные. Так порядок прихода уже не критичен.

UFO landed and left these words here

Если зависимых объектов несколько, то да, они тоже уходят в «ожидание», пока не появится ключевая сущность. Это позволяет держать целостность и не плодить пустые записи.

Подход с болванками мы тоже рассматривали. Он выглядит логично, но в больших обменах приводит к куче «пустышек», которые потом трудно отличать от реальных данных. В результате выше риск ошибок и лишних связей.

Мы нашли баланс: для критичных сущностей (например, клиент) иногда создаем минимальную «болванку», чтобы можно было на неё сослаться. Но в общем случае проще и надежнее держать в статусе ожидания и достраивать, когда данные реально пришли

Sign up to leave a comment.

Articles