Как правильно реализовать получение данных из чужой системы?

У нас с продактом в который раз уже возникает спор, что из чужой БД читать -- такая себе история. Мои аргументы:

  • могут схемы поменяться
  • могут способы заполнения данных измениться

Давай лучше на асинхронных контрактах жить

Его аргументы:

  • контракты тоже могут измениться и способ заполнения данных может поменяться.

Где и что я упускаю?


Ответы (2 шт):

Автор решения: Kromster

Поменяться может все что угодно, как любая схема, так и протокол, и права доступа и вообще добро на взаимодействие между системами.

Подобное решение лежит не в сфере области программирования, а в заключенном "контракте" между вами и "чужими". Такой контракт описывает некоторое API (англ. Application Programming Interface — описание способов взаимодействия одной компьютерной программы с другими), способ реализации которого, обычно разделяемый на сам формат и на его транспорт - уже детали. Будут это фиксированные таблицы БД, хранимки, или REST + xml/json в каком-либо формате, ftp+csv, или ещё что-угодно - обговаривается с "чужими".

Если "чужие" имеют некоторый жизненный опыт, то их API будет отделен (decoupled) от их основной системы (можно рассматривать их систему как Model, а API - как View) и либо максимально лаконичен (KISS and DRY), либо реализован по какому-либо общепринятому стандарту вашей предметной области (например Dicom).

→ Ссылка
Автор решения: CrazyElf
  1. Читать из чужой БД - на мой взгляд хуже, потому что вы должны чётко разбираться в чужой базе. А там реально может поменяться всё, что угодно, данные могут вообще в другие таблицы переехать, например.
  2. Некий контракт в виде API, некой витрины/вьюхи/процедуры в базе и т.п. - лучше, потому что вам не нужно знать их базу досконально, достаточно знать, как обратиться к предоставляемому вам заранее описанному интерфейсу. А те, кто ведут эту базу, лучше знают, как из их базы предоставить нужные данные в заранее обговоренном формате.

Да, в обоих вариантах будут сложности при каких-то изменениях в БД-источнике, но теоретически они должны лучше перевариваться во втором варианте. Хотя, конечно, универсальных решений нет - например, БД может вести один человек, который весь в задачах и ему некогда заниматься ещё и этим API, оно у него по остаточному принципу, ему главное, чтобы база работала 24/7. А у вас при этом полно времени и компетенций, чтобы самим разбираться с изменениями в БД. В этом случае первый вариант будет удобнее, чем ждать, пока у этого админа появится время и желание исправлять API.

→ Ссылка