Srovnání moderních software architektur

Dobrá architektura je jednoduchá, robustní a navržena tak, aby byla snadno udržovatelná a rozšiřitelná, s důrazem na správné rozvržení funkcionalit a dobré řešení závislostí mezi komponentami. Kromě toho by měly být architektury přizpůsobivé změnám a měly by umožnit rychlou reakci na nové požadavky a příležitosti.

Moderní způsoby navrhování software na míru se vyznačují zohledněním potřeb a požadavků konkrétního zákazníka. Tyto způsoby se zaměřují na spolupráci se zákazníkem a získání hlubšího porozumění jeho potřebám. Tímto způsobem se softwarový projekt stává přizpůsobivým a účinným nástrojem pro zákazníka.

Když se podíváme na tradiční architektury, tak vidíme, že zde dominuje architektura monolitu, kde celá aplikace je vyvíjena a nasazována jako celek. Tato architektura má své výhody, jako například jednoduchost vývoje a nasazení, ale také několik nevýhod, jako například pomalou rychlost vývoje a špatnou škálovatelnost. Dnes se podíváme na to, jakými způsoby lze tuto architekturu rozšířit.

Správa infrastruktury

Serverless architektura

• Usnadňuje práci tím, že vývojáři mohou psát a nasazovat kód, aniž by se museli starat o infrastrukturu.
• Veškerá správa infrastruktury a škálování je prováděna poskytovatelem cloudových služeb. Toto umožňuje vývojářům se soustředit pouze na psaní kódu a poskytovat vysokou úroveň dostupnosti a škálovatelnosti.

Architektura založená na kontejnerech

• Kontejnery umožňují vývojářům vytvářet izolované běhové prostředí pro aplikace.
• Každý kontejner může obsahovat pouze potřebné závislosti a běhové prostředí pro aplikaci, což snižuje velikost aplikace a umožňuje snadnější správu.

Organizace zdrojového kódu

Polyrepo

• Architektura, kde každý projekt má své vlastní repozitáře.
• Toto řešení je ideální pro projekty, které mají mnoho nezávislých částí, mohou být vyvíjeny a aktualizovány samostatně.
• Každý tým nebo jednotlivý vývojář může pracovat na svém vlastním repozitáři a nezávisle na ostatních.
• Polyrepo také umožňuje jednodušší řešení problémů s verzováním, protože každá změna je sledována v samostatném repozitáři.

Monorepo

• Architektura, kde všechny projekty jsou uloženy v jediném repozitáři.
• Toto řešení je vhodné pro projekty, které mají společné části a mohou sdílet kód.
• To znamená, že změna v jedné části může ovlivnit i ostatní části projektu.
• Monorepo také umožňuje snadnější sdílení kódu mezi týmy a řeší problémy s kompatibilitou verzí.

Backend

SOA (Service Oriented Architecture)

• Zaměřuje se na rozdělení funkčnosti softwaru do oddělených služeb.
• Tyto služby jsou pak dostupné pro další aplikace, které je mohou využívat.
• Jednotlivé služby jsou navrženy tak, aby byly co nejvíce nezávislé na ostatních službách, což umožňuje snadnou výměnu nebo aktualizaci jedné služby bez toho, aby bylo třeba měnit celou aplikaci.

EDA (Event-driven architecture)

• Umožňuje vývojářům vytvářet aplikace, které reagují na události v reálném čase.
• Doplňuje architektury orientované na služby, protože tyto služby mohou být aktivovány spouští spouštěnými na příchozí události.
• Každá změna stavu v aplikaci může vyvolat událost, která spustí reakci v jiné části aplikace. Toto umožňuje vytvoření velmi reaktivního softwaru a výrazně snižuje závislost na časování a výkonnosti jiných částí aplikace.

Monolitická architektura

• Spojuje všechny komponenty aplikace do jednoho celku, což usnadňuje vývoj a nasazení na začátku projektu.
• Jednoduchost vývoje je výhodou, jelikož vše je v jednom modulu. Jak aplikace roste, správa závislostí se stává náročnější.
• Špatná škálovatelnost nastává s růstem aplikace, kdy každá změna může ovlivnit celý systém, což omezuje flexibilitu a zpomaluje nasazení.

Mikroslužby (Microservices)

• Stále častější volbou pro návrh softwaru na míru.
• Umožňuje oddělit aplikaci na menší služby, které jsou navzájem nezávislé a mohou být vyvíjeny a nasazovány samostatně. To umožňuje agilnější vývoj a nasazování softwaru.
• Každá služba může být napsána v jiném jazyce a používat jinou databázi, což umožňuje vývojářům používat nejlepší nástroje pro každou konkrétní službu.

Frontend

Architektura komponent

• Rozděluje aplikaci do menších částí – komponent (např. tlačítko, kalendář, tabulka) a ty jsou vyvíjeny i nasazovány samostatně.
• Umožňuje rychlejší vývoj a škálovatelnost díky svému znovupoužití v aplikaci.
• Stále však zde existují určité problémy s integrací a sdílením kódu mezi jednotlivými komponentami.

Mikrofrontendy (Microfrontends)

• Jedná se o rozdělení aplikace na samostatné izolované sub-aplikace - mikrofrontendy (např. chat, správa rezervací, účetní vizualizace).
• Vychází z architektur komponent, a mají stejné výhody. Nicméně hlavním rozdílem je, že právě tyto sub-aplikace mohou být snadno znovu používány u různých aplikací jako větší celky než jen komponenty.
• Mikrofrontendy mohou nezávisle sdílet pouze ty knihovny a komponentny, které potřebují.
• Tento přístup řeší mnoho problémů, které jsou spojeny s tradičními architekturami frontendu, jako je rychlost vývoje, škálovatelnost a snadná integrace.

Fullstack (zastaralé)

MVC (Model-View-Controller)

• Zaměřuje se na oddělení prezentace dat (View), logiky aplikace (Controller) a datového modelu (Model).
• Tento přístup umožňuje snadnou úpravu jednotlivých částí aplikace bez toho, aby byly ovlivněny ostatní části.
• Například změna v datovém modelu nemusí mít vliv na způsob, jakým jsou data prezentována v uživatelském rozhraní.

MVVM (Model-View-ViewModel)

• Vychází z architektury MVC, ale přidává další vrstvu – ViewModel, která slouží jako spojovací článek mezi datovým modelem a uživatelským rozhraním.
• Tento přístup umožňuje snadnou separaci kódu pro uživatelské rozhraní a logiku aplikace, což zjednodušuje testování a úpravy.

Shrnutí

Uvedené architektury lze rovněž kombinovat. Například můžeme mít servisovou architekturu (SOA) s několika reaktivními funkcemi v čase (EDA principy), která je plně kontejnerizovaná a napojená na komponentovou architekturu. Polyrepo je vhodné pro projekty, které mají mnoho nezávislých částí, zatímco Monorepo je vhodné pro projekty, které sdílejí společné části.

U menších podniků se obvykle začíná u monolitické architektury, která se postupně drobí na dílčí celky/moduly či jednotlivé služby/komponenty, a optimalizuje se. U větších aplikací, na kterých pracuje klidně i několik desítek vývojových týmů se obvykle naopak po návrhu architektury zahajuje práce přímo na jednotlivých mikroslužbách a mikrofrontendech.

Každá z architektur má své výhody a nevýhody a volba závisí na potřebách a cílech konkrétních projektů. Při návrhu architektury je rovněž velice zásadní zohlednit dlouhodobý rozpočet projektu a kapacity týmu.

Závěrem bychom chtěli zdůraznit, že každých pár let se architektonický přístup k vývoji software dramaticky inovuje. Firmy se pak snaží držet krok s dobou, aby jim konkurence neutekla, nicméně řada z nich zvolí novou architektonickou cestu špatně, zvýší si pouze technologický dluh a dlouhodobě náročně spravují polovičaté řešení nebo nadále pokračují ve starých kolejích. V takových případech vždy doporučujeme poradit se s odborníkem.

Věříme, že nyní lépe chápete rozdíl mezi architektury v rámci vývoje software na míru. Pokud by tě to zajímalo víc do hloubky nebo máš další otázky ​​– jsme tu pro tebe.