Wstęp
Kiedy rozmawiamy o architekturze oprogramowania, szybko pojawiają się nazwy: monolit, mikroserwisy, event-driven, SOA czy modularny monolit. Problem w tym, że te pojęcia często trafiają do jednego worka. W efekcie pytanie „który styl jest najlepszy?” zastępuje ważniejsze pytanie: „jaki problem próbujemy rozwiązać?”.
Ten artykuł otwiera serię o stylach architektury oprogramowania. Jego zadaniem nie jest nauczyć każdego stylu naraz, lecz dać Ci mapę, dzięki której kolejne odcinki i artykuły będą układały się w całość.
Czym jest styl architektoniczny?
Styl architektoniczny to wysokopoziomowy, powtarzalny sposób organizacji systemu. Opisuje podział odpowiedzialności, współpracę komponentów i sposób wdrażania systemu.
Nie należy mylić go z technologią. Kafka, Docker czy Kubernetes mogą być częścią rozwiązania, ale same nie są stylami architektonicznymi. Tak samo wzorce takie jak Saga czy CQRS rozwiązują konkretne problemy i nie są prostą alternatywą dla monolitu.
Dwa podejścia, które porządkują serię
Na potrzeby tej serii dzielimy style na monolityczne i rozproszone.
Ten podział jest użytecznym uproszczeniem. W różnych książkach lub kontekstach możesz spotkać inną klasyfikację, zwłaszcza dla architektury warstwowej. Najważniejsze jest zrozumienie kompromisów, a nie wygranie sporu o etykietę.
Co oznacza monolit?
Monolit jest jedną jednostką wdrożeniową. Najczęściej oznacza to, że interfejs, logika biznesowa i dostęp do danych trafiają na produkcję razem.
Przykład: sklep internetowy z katalogiem produktów, koszykiem i płatnościami działa jako jedna aplikacja. Taki system może być mały albo duży — „monolit” nie oznacza automatycznie złego kodu.
Zalety monolitu
- prostszy start i mniej infrastruktury;
- łatwiejsza diagnostyka w jednym procesie;
- prostsze lokalne uruchamianie;
- mniej problemów z komunikacją sieciową.
Ograniczenia monolitu
- skalowanie najczęściej obejmuje całą aplikację;
- awaria jednego procesu może dotknąć większej części systemu;
- bez dyscypliny granice modułów mogą się zacierać.
W pierwszej części serii omówimy cztery style monolityczne: Layered Architecture, Pipes and Filters, Microkernel oraz Modular Monolith.
Co oznacza system rozproszony?
System rozproszony składa się z wielu współpracujących elementów wdrażanych osobno. Mogą komunikować się synchronicznie przez API lub asynchronicznie przez zdarzenia.
To daje możliwość niezależnego wdrażania i skalowania fragmentów systemu. Przykładowo usługa katalogu może obsłużyć wzmożony ruch bez skalowania całego procesu płatności.
Zalety podejścia rozproszonego
- niezależne wdrożenia i skalowanie;
- możliwość izolowania części awarii;
- wyraźniejsze granice odpowiedzialności, jeśli wynikają z domeny.
Cena za elastyczność
- zawodność i opóźnienia sieci;
- trudniejsza obserwowalność;
- koordynacja danych i transakcji rozproszonych;
- większe wymagania operacyjne oraz organizacyjne.
W drugiej części serii przejdziemy przez Service-Based Architecture, Event-Driven Architecture, Space-Based Architecture, SOA i mikroserwisy.
Mikroserwisy nie są „następnym poziomem” monolitu
To ważne: mikroserwisy nie są automatycznym celem rozwoju każdej aplikacji. Często lepszym krokiem jest uporządkowanie modularności wewnątrz monolitu. Rozproszona architektura ma sens wtedy, gdy jej dodatkowa złożoność rozwiązuje konkretny problem.
Dobry wybór zależy między innymi od domeny, liczby zespołów, oczekiwanego sposobu skalowania, częstotliwości wdrożeń i kompetencji operacyjnych.
Style systemu a architektura aplikacji
Mikroserwisy opisują organizację całego systemu. Natomiast Clean Architecture czy Hexagonal Architecture opisują zwykle wnętrze pojedynczej aplikacji lub usługi. Mikroserwis może korzystać z Clean Architecture, a modularny monolit z podejścia heksagonalnego.
W osobnej serii omówimy te style na poziomie aplikacji.
Co dalej?
W kolejnym materiale zaczynamy od Layered Architecture. To klasyczny podział na warstwę prezentacji, logikę biznesową i dostęp do danych — prawdopodobnie najczęściej spotykany punkt wejścia do projektowania aplikacji.
Obejrzyj odcinek otwierający serię i zapisz się do newslettera, jeśli chcesz dostawać praktyczne wskazówki dotyczące architektury oprogramowania.
Poprzedni artykuł w ścieżce Architektura:
Następny artykuł w ścieżce Architektura: