Итак, в случае примера нам нужно начать с интеграции. Но возникает вопрос: а что интегрировать-то, если ещё ничего не сделано? Даже прототипов нет. Здесь нужно создавать то, что я называю «пред-MVP» — ещё не конечный продукт, но заглушку, позволяющую интегрироваться. Для того же единого окна делалась база данных, в которой размещено условных десять товаров, и мы эти товары по API пытаемся залить в Озон, Вайлдберис, Яндекс и смотрим, чтобы происходили обновления остатков, падали заказы. По сути, на своей стороне мы поднимаем только небольшую базу данных да небольшой контроллер для обработки заказов – просто чтобы нам на страничку выводилось «заказ принят».
Комментарий недоступен
Тут автор прав, я делал различные агрегаторы в свое время.
Лучше сначала изучить API каждого сервиса, за много лет они все примерно приходят к одному и тому же. Нужно выделить это общее, тогда интеграция с последующими сервисами и сами интерфейсы не будут противоречить этой логике.
Если отталкиваться от красивых интерфейсов, то скорей всего их все равно придется переделывать, даже костыли могут не помочь, потому что в них может быть неправильный общепринятый порядок действий и данных.
Не стану претендовать на истину в последней инстанции, но скажу как человек, который руководил разработкой и внедрением двух сложных ERP-систем. Подход "завтра вы захотите использовать другую БД и поэтому давайте использовать БД как гроб данных, а всю транзакционную логику выносить в приложение" — очень дорогой способ абстрагирования. Реальные системы изначально проектируются с прицелом на конкретную СУБД, чтобы взять максимум от ее возможностей. В реальных и действительно сложных системах (банки, логистика, телеком и т.д.) почти вся бизнес-логика хранится в процедурах на стороне БД. Хорошо это или плохо — вопрос философский. Но это как минимум оптимальнее по затратам на сопровождение таких систем.
Спроектировали Вы приложение, реализовали, начали данные загонять из API и выясняется что неудастся получить необходимые данные в нужном формате, а бюджет уже израсходован.
Правильно автор пишет, что если есть в ТЗ черный ящик, нужно либо с него начинать, либо более детально прописывать ТЗ чтобы этот черный ящик превратился в белый
Опытные разрабы или аналитики понимают что такое апи, и оценивают его. А если есть системный аналитик, то описывается еще и каждый параметр при взаимодействии с апи.
Для тех кто не на столько опытен, да, для них эта ошибка "не на поверхности ". А для тех кто строит свой сервис на основе пачки других сервисов, то проработка апи встаёт на первый план, а уже всякие интерфейсы на второй.
Кстати прототипы можно рисовать еще в сервисе https://wmtools.ru
Недавно запустился, и для предпроекта хорошо подходит
Хороший разбор. Сам принял продукт от аутсорсной команды, который разрабатывали по такому же принципу. Первую версию мы запускали уже внутренней командой. Все критичные баги возникают в интеграции. Она жутко медленная. Разработка в ней рискованная и тоже медленная. А начиналось красиво - интерфейсы и все работало во внутреннем контуре.