Vyčlenenie služby presúva ucelenú funkciu z existujúcej aplikácie do samostatne nasadenej služby. Nová služba prijíma požiadavky prostredníctvom explicitného kontraktu a plne vlastní správanie, ktoré jej bolo pridelené. Pôvodná aplikácia môže naďalej obsluhovať zvyšok systému, zatiaľ čo volajúci sa presúvajú v kontrolovaných etapách.
Čo všetko sa musí presunúť
Skopírovanie tried do nového repozitára samotné vyčlenenie nedokončí. Daná funkcia závisí aj od dát, biznisových pravidiel, volajúcich, plánovaných úloh, oprávnení a prevádzkového správania. Každá z týchto závislostí si vyžaduje vlastníka na oboch stranách novej hranice.
| Oblasť záujmu | Pred vyčlenením | Vyžadované rozhodnutie |
|---|---|---|
| Rozhranie | Interné volania | Verejný kontrakt a spracovanie chýb |
| Dáta | Priamy prístup k tabuľkám | Ktorý komponent vlastní jednotlivé zápisy |
| Volajúci | Importy alebo lokálne volania | Smerovanie a poradie migrácie |
| Prevádzka | Zdieľaný behový čas (runtime) aplikácie | Nasadenie, logy a obnova |
Vyčlenená služba môže použiť odlišnú implementáciu, no jej kontrakt musí bezpodmienečne zachovať správanie, ktoré súčasní volajúci naďalej vyžadujú.
Výber hranice
Kandidát na vyčlenenie by mal mať ucelené pravidlá a hranicu, ktorú tím dokáže jasne opísať. Tento modelový rámec môže poskytnúť ohraničený kontext. Modul s obmedzenými prichádzajúcimi a odchádzajúcimi závislosťami sa zvyčajne presúva oveľa jednoduchšie než kód, ktorý sa využíva naprieč celou aplikáciou.
Audit overuje nasledovné skutočnosti:
- Biznisová súdržnosť (business cohesion). Správanie slúži jednej jednoznačne rozpoznateľnej funkcii.
- Prehľad o volajúcich (caller inventory). Každá aplikácia, úloha a integrácia, ktorá danú funkciu využíva, je presne zmapovaná.
- Vlastníctvo dát (data ownership). Jeden komponent sa môže stať hlavnou autoritou pre každý upravovaný záznam.
- Stabilita kontraktu (contract stability). Požiadavky, odpovede a chybové stavy sa dajú zadefinovať explicitne.
- Overenie (verification). Testy alebo porovnania počas behu dokážu potvrdiť správne správanie počas presunu.
Tieto overenia určujú, či je vyčlenenie praktickým krokom migrácie alebo iba architektonickým zámerom.
Postupnosť vyčlenenia v etapách
Tím najprv umiestni danú funkciu za rozhranie vo vnútri monolitu. Súčasní volajúci prejdú na toto rozhranie, zatiaľ čo implementácia zostáva lokálna. Následne sa nasadí nová služba a rozhranie do nej presmeruje vybranú prevádzku. Vlastníctvo dát sa presunie podľa vopred definovaného postupu a odstráni sa priamy prístup z pôvodnej aplikácie.
Na postupné nahrádzanie správania využíva tento typ smerovania Vzor postupného nahrádzania (Strangler Fig Pattern). Paralelný beh síce môže uľahčiť porovnávanie správania, ale operácie zápisu potrebujú jasnú autoritu, aby sa predišlo konfliktným stavom.
Čo môže presun zablokovať
Najkomplikovanejšie závislosti často maskuje zdieľaná databáza. Iné moduly môžu čítať alebo aktualizovať rovnaké tabuľky, databázové triggery môžu vykonávať ďalšiu prácu a reporty sa môžu spoliehať na aktuálnu schému. Vyčlenenie kódu, pri ktorom sa ponechajú neobmedzené zdieľané zápisy, nevedie k vytvoreniu skutočne nezávislého vlastníctva.
Audit legacy kódu (legacy codebase audit) preto pred plánovaním presunu mapuje graf závislostí, prístupy k databáze a prevádzkové požiadavky. Plán potom môže určiť poradie pre tvorbu kontraktov, migráciu volajúcich, oddelenie dát a odstavenie starej cesty. Vyčlenenie služby je kompletné vtedy, keď sa nová služba dokáže meniť a fungovať v rámci svojej definovanej hranice bez toho, aby sa spoliehala na nezdokumentovaný prístup k pôvodnej aplikácii.
