Do zdieľanej databázy pristupuje napriamo viac než jeden modul, služba alebo aplikácia. Títo konzumenti môžu čítať tie isté tabuľky, aktualizovať rovnaké záznamy alebo sa spoliehať na uložené procedúry a triggery. Toto usporiadanie môže byť zámerné, no robí z databázovej schémy súčasť efektívneho rozhrania každého jedného konzumenta.
Ako zdieľanie vytvára previazanosť
Priamy prístup umožňuje konzumentovi závisieť od detailov, o ktorých vlastník dát nemusí ani tušiť, že sú verejné. Premenovaný stĺpec, zmenené obmedzenie (constraint) či upravená hodnota stavu môžu ovplyvniť inú aplikáciu bez toho, aby medzi ich repozitármi existovala akákoľvek závislosť na úrovni kódu.
| Zdieľaný prvok | Skrytá závislosť | Dôkazy pri audite |
|---|---|---|
| Tabuľky a pohľady | Konzumenti závisia od podoby schémy | Logy dopytov (query logs) a hľadanie v zdrojoch |
| Uložená logika | Pravidlá bežia mimo aplikačného kódu | Procedúry, funkcie a triggery |
| Prihlasovacie údaje | Prístup je širší než samotné vlastníctvo | Oprávnenia (grants), roly a nastavenia pripojenia |
| Dávkové exporty | Predpoklady o načasovaní a formáte na strane príjemcu | Úlohy (jobs), súbory a plány |
Závislosť existuje aj vtedy, keď konzument vykonáva výhradne operácie čítania. Reporty, cachovanie a integračné úlohy môžu aj tak výrazne obmedziť to, kedy sa môže schéma alebo pravidlo uchovávania dát zmeniť.
Čo všetko audit mapuje
Vyhľadávanie v repozitároch síce odhalí dopyty a mapovania objektov, no môže vynechať externé reporty, manuálne skripty či aplikácie spravované inde. Analýza databázy počas behu dokáže odhaliť aktívnych používateľov a príkazy. Rozhovory s tímami a konfigurácia nasadenia dopĺňajú kontext o vlastníctve, ktorý technické stopy neobsahujú.
Evidencia zaznamenáva:
- Čitatelia a zapisovatelia (readers and writers). Každý známy konzument a operácie, ktoré vykonáva.
- Autoritatívne polia (authoritative fields). Ktorý komponent určuje platnú hodnotu pre každý dôležitý záznam.
- Uložené správanie (stored behaviour). Pravidlá implementované v triggeroch, procedúrach, predvolených hodnotách a obmedzeniach.
- Predpoklady o načasovaní (timing assumptions). Úlohy alebo exporty, ktoré závisia od poradia aktualizácií a dostupnosti.
- Hranice prístupu (access boundaries). Prihlasovacie údaje a oprávnenia, ktoré jednotliví konzumenti používajú.
Táto mapa sa stáva súčasťou grafu závislostí (dependency graph) pre legacy systém.
Oddelenie vlastníctva od úložiska
Modulárny monolit si môže ponechať jednu fyzickú databázu a zároveň priradiť vlastníctvo tabuliek alebo schém jednotlivým modulom. Ostatné moduly potom namiesto priameho zápisu dát využívajú určené rozhranie. Týmto sa obnovuje logická hranica ešte pred akýmikoľvek zmenami v infraštruktúre.
Vyčlenenie služby zavádza hranicu nasadenia, no nevyžaduje okamžitý presun databázy v každom prípade. Migrácia môže najskôr smerovať zápisy cez budúceho vlastníka, potom presmerovať čítania a až neskôr presunúť samotné úložisko. Každá fáza potrebuje jasne určenú autoritu, aby dva komponenty nerobili konfliktné zmeny.
Plánovanie bezpečného prechodu
Migračný plán začína pri konzumentoch, ktorí už využívajú stabilné rozhranie. Priame dopyty sa nahrádzajú na základe rizika a biznisovej dôležitosti. Kompatibilné pohľady (compatibility views) alebo prekladový kód môžu prechod podporiť, ak sú jasne zaznamenané podmienky ich neskoršieho vyradenia.
Audit legacy kódu (legacy codebase audit) spája zdieľanú databázu s monolitom, jeho ohraničenými kontextmi a funkciami vybranými na zmenu. Tieto fakty určujú poradie migrácie. Cieľom nie je rozdeliť úložisko samo pre seba. Cieľom je spraviť vlastníctvo dát a dopad zmien natoľko explicitným, aby sa dal každý ďalší krok refaktoringu bezpečne overiť.
