Tak abych snad vysvětlil, o jakém receptu zde mluvíme. Cibulová architektura je přístup k návrhu vrstev aplikace. Špagety, neboli špagetový kód, je takový kód, který je těžce oddělitelný, propletený a prochází několika vrstvami aplikace. Takový kód je velice těžce upravitelný či rozšířitelný o nové funkce. Cibulová architektura je tedy opravdu jeden z receptů, jak bychom se mohli vyhnout přípravě špaget.
Proč zrovna cibule?
Jak víme, od cibule je vcelku jednoduché oddělovat i napojovat vrstvy. Dobře. Napojování vrstev cibule na sebe asi nikdo nedělá, ale k představě nám to může posloužit dobře. Architektura cibule se skládá z jádra a vrstev. Co by mělo být v aplikaci jádrem?
Měla by to být prezentace aplikace? Abychom se chápali. Slovním spojením prezentace aplikace myslím tu část aplikace, která jí dává vzhled. V softwarovém vývoji se tato část řeší různými technologiemi jako je WPF, Angular či React. A čím se cibule prezentuje? Řekl bych, že slupkou. Z hlediska vzdálenosti se slupka od jádra cibule nachází nejdál. Takže prezentaci aplikace můžeme zavrhnout.
Měla by to být databáze? Pojďme se nad tím zamyslet. V databázi nalezneme informace. Jaké informace o cibuli víme? Cibule může nabývat různé barvy, odrůdy, chutě či vzhledu. Pokud mohou informace nabývat různých hodnot, jsou proměnlivé. Pokud je něco proměnlivé, nemůžeme na tom stavět. Nemáme totiž pevně dané jádro. Databázi zavrhujeme také.
Co definuje cibuli jako takovou? Dle mého skromného názoru ji definují geny. Co je to gen? Podle Wikipedie je gen jeden ze základních genetických pojmů. Používá se ve dvou základních významech: jako synonymum pro vlohu a jako pojmenování pro konkrétní úsek DNA. Jakožto vloha je gen vlastně jednotka informace, dle níž se vytváří podoba organismu.
Pro naši věc bych si dovolil použít vhodnějšího slova v definici, než je slovo „podoba“. Jelikož podoba je dosti spojována se vzhledem, který by mohl čtenáře přivést zpět ke slovnímu spojení prezentace aplikace. Synonymem slova podoba je slovo „forma“.
Co nebo kdo formuje softwarové aplikace? Programátor? Nikoliv. Zjednodušeně řečeno, programátor překládá zadání v lidské řeči do řeči počítače. Takže softwarovou aplikaci formuje zadání. Zadáním je seznam kritérií, která má aplikace splňovat. Pro definici jednoho kritéria zadání nám v softwarovém inženýrství slouží anglický výraz bussiness rule. Takže výsledek našeho brainstormu je:
Jádro aplikace určují pravidla, neboli bussiness rules, která má aplikace splňovat.
Cibulová architektura
V cibulové architektuře se jádro aplikace dělí na dvě vrstvy. Domain vrstva ji obalující vrstvu application.
Ve vrstvě Domain si budeme udržovat entity a hodnotové objekty naší aplikace. Jako entitu lze chápat každou třídu popisující chování objektu reálného světa, jejíž jedinečnost je určena hodnotou identifikátoru. Například jedinečnost každého Čecha je ve státním systému určena pomocí rodného čísla. Hodnotový objekt musíme chápat jinak.Hodnotový objekt je objekt, jehož jedinečnost je určena jeho hodnotou. Například telefonní číslo či adresa.
Část jádra, nazývající se application, zastřešuje veškerou práci prováděnou s entitami či hodnotovými objekty. V úvodu jsme zmínili pravidla, neboli bussiness rules. Jako příklad si můžeme představit například pravidlo „ulož zákazníka“. Moment. Ale takové pravidlo bude určitě potřebovat pracovat s databází. A v úvodu jsme si jasně řekli, že v jádře se databáze nenachází. Kde je tedy databáze?
Nalezneme ji ve vrstvě persistence, na obrázku vyznačené zelenou barvou. Na obrázku je šipkou naznačena závislost vrstvy persistence na vrstvě application. Konkrétněji vrstva application nesmí využívat třídy definované ve vrstvě Persistence.
Jak tedy implementovat ukládání zákazníka bez možnosti zavolání třídy z vrstvy persistence? Vrstvu persistence si v cibulové architektuře můžete představit jako plugin do vrstvy application. Co potřebujeme, abychom plugin mohli zapojit? Rozhraní. Kde se bude nacházet? V jádře aplikace. Ve vrstvě application si budeme držet rozhraní a jeho konkrétní implementaci naprogramujeme do vrstvy pluginu samotného.
Tomuto přístupu se říká dependency inversion principle. Přístupem získáváme technologickou nezávislost na použité databázi. Databáze se stává implementačním detailem a naše jádro je kompletně separováno od možných vnějších vlivů způsobené databází.
Stejnou motivací jsou vytvořeny zbývající vrstvy presentation a infrastructure. U vrstvy presentation název napovídá, že se jedná o již zmiňovanou prezentaci aplikace. Jelikož se nám technologie pro tvorbu uživatelských rozhraní mění jak na běžícím páse, je dobré i tuto vrstvu od jádra aplikace rozdělit. Obzvláště ve webových technologiích vychází nový javascriptový framework pomalu každým dnem.
Oddělenost prezentace aplikace nám přináší další výhodu z hlediska množství existence druhů elektronických zařízení. Každý programátor mi dá za pravdu, když řeknu, že prezentační vrstva bude nejlépe na zařízení fungovat, pokud bude napsána v nativní technologii zařízení.
Zbývá nám vrstva infrastructure. Ta slouží ke shlukování implementací komunikací s dalšími externími technologiemi, na kterých nechceme být závislí. Může se například jednat o technologii zodpovědnou za odesílání emailů z vaší aplikace nebo tisk souborů.
Shrnutí a užitečné odkazy
Cibulová architektura je konkrétní implementační návrh podporující dogmata knihy Clean Architecture, jejíž autorem je Robert C. Martin. Mnou vysvětlená verze cibulové architektury byla navrhnuta softwarovým architektem Jasonem Taylorem. Kompletní repozitář s ukázkovou aplikací je možné nalézt na GitHubu.
Cibulovou architekturou dosáhneme maximální oddělitelnosti životně důležitých pravidel od vnějších technologií. Pokud nezapředeme do našich bussiness rules vnější technologie, jsme schopni mnohem lehčím způsobem vnější technologii vyměnit. Architektura umožňuje snadnější použití moderních způsobů vývoje, jako je Domain Driven Design a Test Driven Development.
