Když vstupuji do týmu, který začíná stavět nový systém, často se brzy dostaneme k databázi, infrastruktuře a konkrétním službám. V čem to napíšeme. Kde to poběží. Co na co připojíme.
Rozumím potřebě mít něco pevného, od čeho se můžeme odrazit. Sám ale v tu chvíli přemýšlím také o tom, kolik z budoucího řešení už skutečně známe.
Na projektech, kterých jsem byl součástí, se představa o potřebách businessu během vývoje dál měnila. Něco se vyjasnilo až při prvním použití. Jiné požadavky vznikly teprve nad tím, co jsme dodali.
Proto pro mě není každé odložené rozhodnutí známkou nedostatečné přípravy. Někdy je to naopak výsledek toho, že jsem se připravil na změnu.
Dobrá architektura pro mě není ta, ve které jsme všechno správně rozhodli na začátku. Je to ta, ve které si můžeme dovolit rozhodnout později, aniž bychom zastavili vývoj.
Když jsme měli začít, ale nevěděli jsme, kde to poběží
Při realizaci projektu pro státní pokladnu jsme na začátku neznali finální provozní prostředí. Neměli jsme kontakt na lidi, kteří budou infrastrukturu zajišťovat, a její konkrétní podoba se postupně upřesňovala a měnila.
Z pohledu vývoje to bylo poměrně nejisté prostředí. Současně jsme potřebovali řešení dodat rychle a ve vysoké kvalitě.
Mohl jsem čekat na odpovědi. Nebo si některou z variant vybrat a doufat, že už se nezmění. Ani jedna cesta mi nepřipadala dobrá.
Potřeboval jsem oddělit práci, kterou můžeme dělat už teď, od rozhodnutí, pro která ještě nemáme dost podkladů.
Právě tady pro mě přestává být architektura pouze představou výsledného systému. Začíná určovat i to, jak se k němu dokážeme dostat.
Co jsem potřeboval vědět a co ještě mohlo zůstat otevřené
Neznamenalo to, že nemusím vědět nic.
Potřeboval jsem rozumět tomu, co má aplikace dělat, jaké odpovědnosti v ní budou a co očekává od okolních služeb. Potřeboval jsem jejich kontrakty a způsob, jak ověřovat, že jim naše implementace odpovídá.
Rozdělil jsem proto řešení na malé části s oddělenými komponentovými rozhraními. Business logika mohla pracovat s tím, co potřebuje získat nebo předat, aniž by byla přímo svázaná s konkrétním technickým napojením.
V tom mi pomáhá Dependency Inversion: závislosti vedou k abstrakcím vyjadřujícím potřeby aplikace a konkrétní infrastruktura se připojuje přes jejich implementace. [1]
Moje práce tedy nespočívala v tom, že jsem rozhodnutí prostě neudělal. Rozhodl jsem o hranicích, díky kterým mohlo něco jiného zůstat otevřené.
Tento rozdíl považuji za podstatný. Když neumím říct, co jsem oddělil a jak to ověřím, nemám zatím důvod věřit, že pozdější změna bude snadná.
Okolní služby nemusely být hotové, abychom mohli pracovat
V Azure jsme si vytvořili vývojové a testovací prostředí s nízkými provozními náklady. Měli jsme syntetická data a simulovali potřebné chování budoucích služeb státní pokladny.
Od přístupu k datům podle dostupných kontraktů přes bezpečnostní dohled až po ukládání logů a vyhledávání přes Elasticsearch jsme si připravili prostředí, na kterém bylo možné aplikaci vyvíjet a ověřovat.
Nešlo mi o to vyrobit kopii celého světa zákazníka. Potřeboval jsem, aby naše aplikace dostávala takové odpovědi a mohla provádět takové interakce, se kterými má podle kontraktů pracovat.
Tomuto oddělení odpovídá i přístup ports and adapters: aplikace komunikuje přes vymezená rozhraní a za nimi může být produkční nebo testovací implementace. [2]
Měl jsem tak dva až tři měsíce na implementaci a ladění business logiky. Nemusel jsem tuto práci odložit až na okamžik, kdy bude definitivně známé celé cílové prostředí.
Jak se architektura zpřesňovala, mohli jsme měnit jednotlivá napojení a způsob sestavení aplikace. Třeba vytvořit jiný runner, který komponenty zapojí a spustí v daném prostředí.
To, co už jsme si ujasnili v business pravidlech, jsme kvůli tomu nemuseli znovu otevírat.
Simulace mi dává podklad, ne poslední odpověď
Tady si ale potřebuji držet hranici mezi tím, co už jsme ověřili, a tím, co teprve ověřit musíme.
Když aplikace funguje proti našim testovacím implementacím, vím něco o jejím chování vůči kontraktům, které jsme v těchto implementacích vyjádřili. Ještě tím nevím všechno o skutečné službě a cílovém provozu. I při použití ports and adapters zůstávají integrační testy proti skutečným systémům samostatným krokem. [2]
Potřebuji ověřit například chování při chybách, oprávnění nebo skutečný způsob práce s daty. Pokud měním úložiště, musím se zabývat také migrací dat.
Když tedy říkám, že mi oddělení infrastruktury zlevňuje změnu, nemyslím tím, že změna nemá žádnou cenu.
Myslím tím, že kvůli ní nemusím zbytečně měnit i to, co s ní významově nesouvisí.
To je také hranice toho, co chci slibovat zákazníkovi. Ne bezpracnou výměnu libovolné technologie, ale srozumitelný rozsah změny a způsob, jak ověříme její výsledek.
Přemýšlím i o systému, podle kterého systémy tvořím
Postupně jsem si uvědomil, že při návrhu neuvažuji jen o konkrétní aplikaci. Zajímá mě také způsob, podle kterého ji stavím.
Pro sebe tomu říkám metasystém. Systém, na jehož základě vytvářím další systémy.
Není to jeden framework, který bych chtěl použít všude. Je to soubor souvislostí a pravidel, ke kterým se vracím. Jak rozděluji odpovědnosti. Podle čeho poznám, že se jejich význam změnil. Které závislosti potřebuji oddělit. Jak zjistím, že jsem si novou úpravou nerozbil to, co už fungovalo.
Tento způsob práce si můžu zvolit na začátku, i když ještě neznám přesné obrysy výsledného řešení.
Strategii tedy mám. Taktiku rozvíjím během implementace.
Měním sestavení komponent, zpřesňuji napojení, reaguji na nové informace. Pro mě to není rozpor s původním návrhem. Je to způsob, jak ho postupně přibližuji tomu, co skutečně potřebujeme.
Někdy z toho vzniknou části použitelné i na jiném projektu. Považuji to za užitečný důsledek, ne za důvod stavět dopředu univerzální platformu.
Nemusím připravit každou možnou budoucnost
Možnost vyměnit databázi pro mě neznamená, že mám hned napsat podporu pro několik databází. Stejně tak nechci udržovat několik provozních variant jen proto, že se některá možná jednou bude hodit.
Rozlišuji možnost změnu provést a hotovou implementaci každé myslitelné změny.
Tahle hranice mi připomíná YAGNI: neinvestovat předem do schopností, které zatím nepotřebuji. Neznamená to rezignovat na průběžné zlepšování návrhu, ale nezaměňovat ho za výrobu hypotetické budoucnosti. [3]
Na projektu s nejasnou infrastrukturou mi oddělení pomáhalo okamžitě. Díky němu jsme mohli pracovat a testovat. Nebyla to pouze investice do migrace, která možná přijde za několik let.
Podobně chci přemýšlet o každé další vrstvě. Zajímá mě, co mi umožní udělat nezávisle a jakou konkrétní nejistotu tím zvládám.
Pokud si na to nedokážu odpovědět, potřebuji se zastavit. Je možné, že už nevytvářím prostor pro změnu, ale přidávám další věc, které budeme muset rozumět.
Později neznamená až po prvním problému
Rozhodovat co nejpozději pro mě neznamená čekat, až systém přestane stačit v provozu.
Chci rozpoznat okamžik, kdy mám dost podkladů a zároveň ještě čas změnu provést. K tomu potřebuji vědět nejen to, co mi dnes chybí, ale také jak dlouho může trvat přechod k jiné variantě.
Jinak přemýšlím o napojení, které dokážu rychle upravit a otestovat, a jinak o změně, na kterou navazuje schvalování, příprava prostředí nebo migrace dat.
Stejně tak neodkládám otázky bezpečnosti či základních vlastností dat jen proto, že ještě neznám finální platformu. Mohou určovat, jak vůbec smím řešení navrhnout.
Potřebuji tedy udržovat přehled o tom, co zůstává otevřené a proč. Jinak bych si mohl možnost rozhodnout později splést s tím, že jsem na rozhodnutí přestal myslet.
Abych mohl měnit směr po malých krocích
Zkušenost s vyzrálými CI/CD postupy mi ukázala ještě jednu souvislost. Mnohem snáz se mi připouští nedokonalost první verze, když vím, že ji umíme průběžně a bezpečně upravovat.
Automatizované sestavení, testy a kontinuální integrace (CI) dávají zpětnou vazbu potřebnou pro postupný refaktoring. Samotná ochota návrh zlepšovat takové ověřování nenahradí. [4]
Mohu pak začít s jednodušším řešením a podle zkušenosti ho dál rozvíjet. Rozdělit odpovědnost, zpřesnit pojmenování, nahradit komponentu. Nemusím všechny tyto úpravy spojit do jedné velké přestavby.
Označení MVP pro mě v tomto smyslu znamená, že víme, jaké omezení přijímáme. Třeba že současná varianta vyhovuje prvnímu použití, ale při určitém růstu ji budeme muset změnit.
Potřebuji mít představu, podle čeho tento okamžik poznáme. A také reálnou schopnost na něj reagovat.
Bez ní by postupné zlepšování zůstalo jen přáním, kterým si vysvětlíme dnešní zkratku.
Když se moje pravidlo potká s potřebou businessu
Někdy se rozhodneme určité pravidlo nedodržet. Nevidím v tom automaticky problém.
Záleží mi na tom, jestli rozumíme důsledkům a jestli jsme se na nich domluvili předem. U ohraničené změny to může být deset nebo patnáct minut s product manažerem. Co tím získáme teď. Co bude složitější později. Kolik může stát náprava.
Rozdělit interní objekt je jiná situace než přejmenovat veřejnou zprávu, na kterou už někdo navazuje. Nechci obojí označit za technický dluh a dál se rozdílem nezabývat.
Jsou i situace, kdy se problém stane důležitým až při výrazném růstu produktu. Může pro nás být přijatelné zaplatit za jeho řešení později, pokud se do té fáze vůbec dostaneme. Neznamená to, že cenu známe přesně nebo že na ni můžeme zapomenout.
Architektura nesmí stát v cestě businessu. Business ale musí znát cenu svého rozhodnutí.
Tohle pro mě není ústupek technické kvalitě. Je to součást odpovědnosti za výsledek. Potřebuji rozumět nejen tomu, jak řešení postavit, ale také tomu, proč určitou práci dělat právě teď.
Klid, který nevzniká z toho, že znám budoucnost
Když se vrátím k projektu státní pokladny, nejdůležitější pro mě nakonec není to, jakou službu jsme simulovali nebo kde běželo testovací prostředí.
Je to skutečnost, že jsem mohl být v klidu už na začátku, kdy ještě spousta věcí nebyla rozhodnutá.
Neměl jsem jistotu, jak všechno dopadne. Měl jsem ale způsob práce, kterému jsem rozuměl. Věděl jsem, kterou část můžeme ověřovat, kde zatím pracujeme s předpokladem a co budeme měnit, až přijdou další informace.
Právě takovou předvídatelnost chci vytvářet i pro tým a zákazníka. Nemusíme předstírat, že známe celý budoucí systém. Potřebujeme se shodnout na tom, co má vzniknout nyní, kde jsou hranice naší jistoty a jak budeme ověřovat další kroky.
Čím víc nad tím přemýšlím, tím méně pro mě architektura znamená potřebu mít brzy všechny odpovědi. Víc mě zajímá schopnost pokračovat v práci a nové odpovědi do ní postupně promítat.
Rozhodnutí si mohu dovolit odložit jen tehdy, když si uchovám možnost změnu zvládnout.
A právě za vytvoření této možnosti považuji architekta za odpovědného.
Vztáhnout si to na vlastní projekt
Pro vlastní úvahu bych nezačínal výběrem jiného frameworku. Vzal bych jedno rozhodnutí, které dnes na projektu potřebujete udělat, a zkusil oddělit, co o něm už víte, co předpokládáte a co se ještě potřebujete dozvědět.
Potom bych se podíval, jakou práci můžete udělat nezávisle na chybějící odpovědi. Právě tam může být první praktický krok.
Rád s vámi takovou situaci projdu. Můžeme společně hledat, co potřebuje rozhodnutí teď a kde má smysl nejdřív vytvořit podmínky pro další práci.
Zdroje a podklady k dalšímu studiu
Popsané situace a způsob rozhodování vycházejí z mé praxe. K technickým souvislostem přikládám následující podklady.
Zdroje ověřeny 14. října 2026.
[1] Microsoft. Architectural principles. Oddělení odpovědností a Dependency Inversion.
[2] Alistair Cockburn. Hexagonal architecture / ports and adapters. Oddělení aplikace od okolních technologií, testovací implementace a integrační ověřování.
[3] Martin Fowler. Yagni. Rozdíl mezi průběžnou péčí o návrh a předčasnou implementací budoucích schopností.
[4] Martin Fowler. Continuous Integration. Kontinuální integrace a automatické ověřování jako opora evolučního návrhu.