Modulární aplikace: jak vypnout modul a nepřijít o data

Emitent se třemi desítkami investorů zapíše pár plateb za měsíc ručně a provize nikomu nevyplácí. Emitent s několika sty investory a sítí zprostředkovatelů se naopak bez párování bankovních výpisů a výpočtu provizí neobejde. Jedna aplikace pro oba proto potřebuje části, které jde zapnout a vypnout. Zapnout modul je snadné, horší je ho vypnout tak, aby nezmizela data, která vytvořil, a nepřestala platit pravidla, která hlídají peníze. V článku se podíváme na to, podle čeho modul vymezit, jak moduly propojit a jak ověřit, že vypnutí nic nerozbije.

Modulární aplikace – modul je schopnost, kterou si zákazník kupuje

Když vývojář poprvé dělí aplikaci na části, nabízí se mu dělit ji podle techniky: databáze, rozhraní, obrazovky. Pro zákazníka je ale takové dělení k ničemu, protože nikdo si nekoupí „vrstvu rozhraní“. David Parnas už v roce 1972 ukázal, že dobrý modul neodpovídá kroku zpracování, ale rozhodnutí, které se může změnit a které modul skrývá před ostatními [1]. U produktu pro víc zákazníků je takovým rozhodnutím to, jak zákazník pracuje.

Modul proto vymezujeme jako schopnost, kterou si kupuje určitý druh emitenta:

• Banka (výpisy, párování plateb, příkazy pro banku) pro emitenta s mnoha platbami,
• Schvalování druhou osobou pro back office, kde pracuje víc lidí,
• Závěrky pro emitenta, jehož účetní zavírá měsíce,
• Komunikace (e-maily investorům) a Deník (záznamy kontaktů s klienty) pro emitenta, který vede obchod,
• Provize pro emitenta se zprostředkovateli,
• Online prodej pro emitenta, který přijímá objednávky z vlastního webu.

Jedna otázka pomůže rozhodnout sporné případy: kupuje si to zákazník zvlášť? Když dvě funkce nikdo nechce jednu bez druhé, patří do jednoho modulu. Každý další přepínač totiž zdvojnásobí počet kombinací, které musí aplikace ustát, a zákazník z rozdělení nic nemá.

Přepínač modulu je jiný druh přepínače než ten, kterým vývojáři schovávají rozpracovanou funkci. Pete Hodgson v článku na webu Martina Fowlera rozlišuje přepínače podle toho, jak dlouho žijí a kdo je ovládá [2]. Přepínač rozpracované funkce po vydání zmizí, přepínač modulu zůstává v aplikaci roky a ovládá ho zákazník. Obě polohy proto musí být stejně odzkoušené.

Co nikdy není modul: přihlášení, oprávnění, historie změn a zálohy

Při dělení se vždy objeví funkce, které by šlo prodávat zvlášť, ale vypnout se nesmějí. Patří k nim přihlášení a bezpečnost, role a oprávnění, historie změn, zálohy s obnovou a průvodce, který uživatele vede procesem. Tvoří Platformu, na které stojí každá instalace.

Důvod je jednoduchý: na těchto funkcích stojí důvěra v data. Kdyby šla vypnout historie změn, auditor by se po roce nedozvěděl, kdo investorovi změnil účet pro výplatu. Auditní stopa má smysl jen tehdy, když běží pořád, i ve chvíli, kdy ji nikdo nepotřebuje.

Základ obsahuje vše, co ukládá zákon

Nad Platformou stojí Základ, tedy evidence, kterou potřebuje každý emitent bez ohledu na velikost. Emitent listinných dluhopisů musí vést seznam vlastníků, počítat a vyplácet úroky, srazit a odvést daň a doložit, komu co zaplatil. Do Základu proto patří emise, klienti, objednávky, platby, výplaty, srážková daň, dokumenty i podklady pro účetní. Volitelný modul může práci zrychlit, ale zákonnou povinnost na něm postavit nejde.

Druhé pravidlo je méně vidět: data Základu nesmí záviset na volitelném modulu. Ukážu to na prodejcích. Údaj o tom, kdo klienta získal, vypadá jako součást provizí. Jenže z něj čte i pravidlo oprávnění „obchodník vidí jen své klienty“. Kdyby prodejci patřili do modulu Provize, jeho vypnutí by rozbilo oprávnění v Základu. Prodejce proto evidujeme v Základu a modul Provize nad nimi jen počítá peníze. Podobně dopadla kontrola čísla účtu a IBAN: potřebuje ji i ruční zápis platby, takže patří všem, zatímco import výpisů zůstal v modulu Banka.

Moduly spolu mluví přes události, ne napřímo

Když back office stornuje zaplacenou objednávku, má se stát víc věcí najednou: zrušit provize prodejce, zrušit neodeslané e-maily k objednávce a případně připravit oznámení o stornu. Odeslaný e-mail se pak zapíše do deníku klienta. Kdyby to storno v Základu zařídilo přímým voláním provizí a e-mailů, nešel by žádný z těch modulů vypnout bez zásahu do Základu. Základ proto jen ohlásí událost „objednávka stornována“ a moduly, které jsou zapnuté, na ni zareagují. U vypnutého modulu se spustí jen pravidla, která chrání peníze (o nich níže), a storno proběhne stejně.

Ze schématu je vidět i další pravidlo: volitelný modul vyžaduje jen Základ. Mezi sebou se moduly nanejvýš využijí, když je ten druhý zapnutý. Objednávka z online prodeje s prodejcem dostane po úpisu provizi, pokud běží Provize, a Provize vyplatí zprostředkovatele příkazem pro banku, pokud běží Banka. Bez Banky se provize předá do mezd nebo označí jako vyplacená ručně. Vazby vedou jedním směrem a netvoří kruh, jinak by se moduly nedaly vypínat jednotlivě. Hranice hlídá automatický test, takže nová přímá vazba přes hranici modulu neprojde. Další pravidla popisuje článek Funkční mapa aplikace.

Pravidla, která běží vždy, a pravidla jen se zapnutým modulem

Vypnutím modulu zmizí jeho obrazovky a nové akce, jeho záznamy v databázi ale zůstanou. Část pravidel nad nimi musí běžet dál, i když modul nikdo nepoužívá. Rozdělujeme je proto na dva druhy:

• Integritní pravidla chrání peníze a data a běží vždy podle dat. Peníze nesmí odejít dvakrát a výplata musí sedět s příkazem pro banku. Když back office stornuje objednávku při vypnutých Provizích, provize k výplatě se stejně zruší, jinak by po pozdějším zapnutí modulu čekala na vyplacení za obchod, který neexistuje.
• Procesní pravidla popisují způsob práce a platí jen se zapnutým modulem. Schválení druhou osobou se při vypnutém Schvalování nevyžaduje a uzavřený měsíc při vypnutých Závěrkách nic neblokuje.

V praxi platí jednoduchý test: pravidlo je integritní, když by jeho vynechání změnilo peníze nebo údaje, které uvidí někdo mimo aplikaci (banka, investor, finanční úřad). Ostatní pravidla jsou procesní a vypnutý modul je smí vypnout s sebou.

Vypnutí modulu s rozpracovanými položkami

Administrátor obvykle vypíná modul, který se nevyplatil, třeba po půl roce používání. V modulu ale mohou zůstat rozpracované položky: nevyplacené provize, nespárované řádky výpisu, žádosti čekající na schválení nebo online žádosti ve frontě. Po vypnutí by visely bez obrazovky a nikdo by je nedokončil.

Aplikace proto vypnutí odmítne a ukáže seznam rozpracovaných položek s odkazy, kde je dokončit. Teprve s prázdným seznamem modul vypnout jde. Data vypnutého modulu se nikdy nemažou. Přijaté online žádosti, vyplacené provize i historie schválení zůstávají a po opětovném zapnutí jsou zase vidět.

Na snímku z ukázky je u každého modulu napsané, co přestane fungovat. Změna přepínače vyžaduje důvod a zapíše se do historie změn, takže je dohledatelné, kdo modul vypnul a proč.

Zapnutí modulu po době bez něj

Opačná situace nastane, když emitent dva roky pracuje bez modulu Komunikace a pak ho zapne. Kdyby aplikace po zapnutí připravila upomínky ke všem starým nezaplaceným objednávkám, investoři by dostali e-maily k dluhům, které emitent dávno vyřešil jinak. Modul si proto pamatuje den, kdy byl naposledy zapnutý, a upomínky připraví jen k objednávkám s termínem úhrady od tohoto dne. Nic se neposílá zpětně. Banka to řeší jinak: když emitent nahraje starší výpis, řádky, které přesně odpovídají ručně zapsané platbě, se samy spárují a peníze se nezmění. Ostatní řádky čekají na vyřízení jako u každého výpisu.

Před zapnutím aplikace ukáže, co se stane, a nabídne volitelné kroky. U Provizí třeba upozorní, že úpisy z doby bez modulu provizi nemají, a nabídne jim provize dopočítat podle dnešní sazby prodejce. Nic se ale nedopočítá samo: dopočet musí administrátor vědomě zaškrtnout, a to jen tehdy, když prodejcům za tu dobu neplatil mimo aplikaci.

Jak ověřit, že vypnutí nic nerozbije

Že vypnutí modulu nic nerozbije, se nedá dokázat jednou zkouškou v ukázce. Před sloučením změn do hlavní verze proto pouštíme celou sadu testů opakovaně: pokaždé s jedním volitelným modulem vypnutým a nakonec se všemi volitelnými moduly vypnutými najednou. Při změně spolupráce dvou modulů pustíme i dvojici vypnutou současně. Testy vypnutého modulu se přeskočí, všechny ostatní musí projít. Když některý spadne, Základ nebo jiný modul na vypnutém modulu skrytě závisí a změna se do hlavní verze nedostane.

Tahle zkouška je pomalejší než běžné testy, a proto neběží po každé drobné změně. Jak testujeme samotné výpočty, popisuje článek Testování finančních výpočtů a celkový přístup k vývoji Zásady vývoje software.

Závěr

Modul vymezujeme podle toho, co si zákazník kupuje, a přihlášení, oprávnění, historie změn a zálohy jím nejsou nikdy. Zákonná evidence patří do Základu a její data nesmí záviset na volitelném modulu, i když údaj na první pohled patří k modulu (prodejci a provize). Modul jde vypnout bez ztráty dat díky třem pravidlům: moduly se nevolají napřímo, pravidla nad penězi běží vždy podle dat a vypnutí s rozpracovanými položkami se odmítne. IT správce, který modulární aplikaci vybírá, by se měl dodavatele zeptat, co se stane s daty po vypnutí modulu a jak to dodavatel ověřuje.

Reference

1. Parnas, D. L., On the criteria to be used in decomposing systems into modules. Communications of the ACM, 1972, roč. 15, č. 12 [on-line]. [cit. 2026-10-15]. Dostupné z WWW: https://dl.acm.org/doi/10.1145/361598.361623
2. Hodgson, P., Feature Toggles (aka Feature Flags). martinfowler.com, 2017 [on-line]. [cit. 2026-10-15]. Dostupné z WWW: https://martinfowler.com/articles/feature-toggles.html