Wspólna baza jako skrót do integracji

Scenariusz dydaktyczny. To modelowy przypadek, a nie opis konkretnego wdrożenia ani organizacji.

Punkt wyjścia

System obsługi zamówień ma udostępniać statusy do portalu klienta. Zespół chce dotrzymać terminu, więc daje portalowi bezpośredni dostęp do swojej bazy. Na początek portal tylko czyta tabele. Później dostaje uprawnienie do aktualizowania adresu dostawy, bo „to jedna prosta kolumna”.

Co zaczyna się psuć

• Portal zakłada, że określona wartość w kolumnie oznacza zamówienie gotowe do wysyłki. Zmiana znaczenia statusu w systemie źródłowym powoduje błędną informację dla klienta.
• Migracja schematu wymaga skoordynowania wdrożeń obu aplikacji, mimo że miały rozwijać się niezależnie.
• Portal zapisuje adres z pominięciem walidacji i reguł systemu zamówień. W bazie pojawiają się dane, których właściciel procesu nie potrafi poprawnie obsłużyć.
• Dostęp do bazy utrudnia ograniczenie uprawnień do konkretnych operacji i zbadanie, kto wykonał zmianę biznesową.

Gdzie była zła decyzja

Udostępniono wewnętrzny model danych jako kontrakt integracyjny, a następnie oddano drugiemu systemowi prawo do jego modyfikowania. Kolumny i tabele stały się nieformalnym API bez wersjonowania, jawnych zasad i właściciela zmian.

Nie oznacza to, że każdy odczyt repliki lub danych analitycznych jest błędem. Trzeba odróżnić kontrolowany przepływ danych do raportowania od współdzielenia transakcyjnej bazy i logiki zapisu.

Jak podejść lepiej

1. Ustal właściciela zamówienia i adresu dostawy. Zapis wykonuj przez jego jawny kontrakt, który egzekwuje walidację, uprawnienia i reguły biznesowe.
2. Do odczytu dobierz mechanizm do wymagań: API dla bieżącego statusu albo zdarzenia i własny model odczytowy portalu, jeśli dopuszczalne jest opóźnienie. Nie wybieraj asynchroniczności automatycznie; ustal, jaka świeżość danych jest potrzebna.
3. Wersjonuj kontrakt i przewidź okres zgodności podczas migracji. Monitoruj opóźnienia, błędy integracji i rozbieżności.
4. Jeżeli bezpośredni dostęp jest rozwiązaniem przejściowym, ogranicz go, nadaj datę zakończenia i zaplanuj przejście na jawny kontrakt.

Pytania na przegląd architektury

• Kto odpowiada za prawidłowość tych danych i kto może je zmieniać?
• Czy odbiorca musi widzieć zmianę natychmiast, czy może tolerować opóźnienie?
• Jak oba systemy przejdą przez zmianę schematu lub znaczenia statusu?

Reguła: granica własności danych powinna być także granicą zapisu. Integruj się przez uzgodniony kontrakt, którego właściciel może bezpiecznie rozwijać.