Najpopularniejsze wzorce architektoniczne — opisy, diagramy, zalety, wady i przykłady z życia
👤 Klient
→
🧱 MONOLIT
UI · Logika biznesowa · Dostęp do danych
→
🗄️ Baza danych
Całość budowana, testowana i wdrażana jako jeden deployable unit
Architektura monolityczna to klasyczne podejście, w którym cały kod aplikacji — interfejs użytkownika, logika biznesowa i dostęp do danych — jest zbudowany i wdrażany jako jedna, niepodzielna całość. Wszystkie komponenty działają w tym samym procesie, komunikują się przez bezpośrednie wywołania funkcji i współdzielą zasoby. To najprostszy model architektoniczny, który świetnie sprawdza się na starcie projektu — dopóki aplikacja nie urośnie ponad kontrolę.
Jeden codebaseWspólna baza danychJeden deploymentBezpośrednie wywołania funkcjiWspólny model danychJeden proces OS
Zalety i wady
✅ Zalety
✅Prosta w developmencie i debugowaniu — wszystko w jednym miejscu
✅Brak latencji sieciowej między komponentami — wywołania lokalne
✅Łatwe testowanie end-to-end i transakcje ACID bez problemów
✅Niska złożoność infrastrukturalna — jeden serwer/container
✅Szybki start projektu, duże community i znane wzorce (MVC)
❌ Wady
❌Skalowanie wyłącznie poziome całej aplikacji, nawet gdy wąskie gardło to jeden moduł
❌Jeden błąd może zatrzymać całą aplikację (brak izolacji)
❌Długie czasy deploymentu i testów przy dużym projekcie
❌Trudna praca wielu zespołów — konflikty merge, zależności
❌Z czasem kód staje się „big ball of mud" — ciężki w modyfikacji
Przykłady z życia
Netflix (przed 2009)
Jeden wielki monolit Java. Awaria jednego modułu potrafiła wyłączyć całą platformę.
Amazon (early)
Aplikacja PHP — jeden wielki monolit. Właśnie jego bóle doprowadziły do słynnego „API mandate" Bezosa.
Shopify
Do dziś częściowo monolit Ruby on Rails — świadomie zachowany i optymalnie zarządzany.
StackOverflow
Celowo pozostał monolitem ASP.NET. Obsługuje miliony zapytań/dobę na kilku serwerach.
WordPress
Klasyczny PHP monolit zasilający ~43% stron internetowych na świecie.
💡 Kiedy stosować: Nowe projekty i startupy (szybki time-to-market), proste aplikacje CRUD, małe zespoły (1–5 osób), gdy wymagania biznesowe nie są jeszcze ustabilizowane. Zasada „monolith first" — zacznij od monolitu i wydzielaj serwisy dopiero gdy pojawi się konkretna, zmierzona potrzeba.
👤 Klient / Browser
↓
🖥️ Warstwa prezentacji (Controller / View)
↓
⚙️ Warstwa logiki biznesowej (Service)
↓
💾 Warstwa dostępu do danych (Repository)
↓
🗄️ Baza danych
Każda warstwa komunikuje się wyłącznie z warstwą bezpośrednio pod nią
Architektura warstwowa dzieli aplikację na poziome warstwy, z których każda ma ściśle określoną odpowiedzialność. Klasyczny podział 3-warstwowy obejmuje: prezentację (obsługa żądań HTTP, widoki), logikę biznesową (reguły, operacje) i dostęp do danych (repozytoria, ORM). Każda warstwa zależy tylko od warstwy pod nią — nigdy „przez warstwę" i nigdy w górę. To najszerzej stosowany wzorzec w aplikacjach enterprise, stanowiący podstawę większości frameworków (Spring, Laravel, Django, ASP.NET).
„Convention over configuration" — MVC z ActiveRecord jako ORM.
💡 Kiedy stosować: Enterprise CRUD aplikacje z dobrze zdefiniowanymi wymaganiami, systemy z relacyjnymi bazami danych, gdy ważna jest czytelność i maintainability, zespoły znające wzorzec MVC. Idealna jako punkt startowy przed ewentualną migracją do mikroserwisów.
👤 Klient
→
🚪 API Gateway
↓
Serwis A
↓
DB-A
Serwis B
↓
DB-B
Serwis C
↓
DB-C
Serwis D
↓
DB-D
Każdy serwis: własna baza, własny deployment, własny cykl życia
Architektura mikroserwisów rozbija aplikację na zestaw małych, niezależnych serwisów, z których każdy odpowiada za jeden obszar biznesowy (Bounded Context w rozumieniu DDD). Każdy serwis ma własną bazę danych, może być napisany w innym języku i technologii, jest wdrażany niezależnie. Serwisy komunikują się przez REST/gRPC lub message queue. API Gateway pełni rolę jednego punktu wejścia dla klientów zewnętrznych.
Bounded Context (DDD)Własna DB per serwisAPI GatewayService DiscoveryContainer / KubernetesCircuit BreakerDistributed TracingREST / gRPC
Zalety i wady
✅ Zalety
✅Niezależna skalowalność — skalujesz tylko serwis pod obciążeniem
✅Izolacja błędów — awaria Serwisu A nie zatrzymuje Serwisu B
✅Wolność technologiczna — Java, Python, Go w jednym systemie
✅Niezależne deploymenty — szybkie cykle CI/CD per serwis
✅Duże zespoły mogą pracować równolegle (Conway's Law)
❌ Wady
❌Wysoka złożoność operacyjna — service discovery, load balancing, tracing
❌Latencja sieciowa i partial failures — trudne do obsłużenia
❌Brak transakcji między serwisami — eventual consistency
❌Trudniejsze debugowanie — logi rozproszone po wielu miejscach
❌Duży narzut infrastrukturalny — wymaga dojrzałego DevOps
Model „squads i tribes" — małe, autonomiczne zespoły z własnymi serwisami.
Booking.com
Wieloletnia stopniowa migracja z monolitu PHP do mikroserwisów.
💡 Kiedy stosować: Duże, wielozespołowe projekty (10+ developerów), aplikacje z bardzo różnymi wymaganiami skalowalności per moduł, cloud-native systemy na Kubernetes, gdy szybkość deploymentu i izolacja są krytyczne. Nie zaczynaj od mikroserwisów — zacznij od monolitu i wydzielaj gdy pojawi się realna potrzeba.
Klient A
Klient B
Klient C
↓
🔶 Enterprise Service Bus (ESB)
Routing · Transformacja · Orkiestracja
↓
Serwis Płatności
Serwis Klientów
Serwis Zamówień
Serwis Legacy
ESB jako centralny mózg — orkiestracja, routing, transformacja danych
SOA (Service-Oriented Architecture) to architektura, w której funkcjonalności systemu są oferowane jako serwisy komunikujące się przez centralny Enterprise Service Bus (ESB). ESB pełni rolę „smart pipe" — zarządza routingiem, transformacją danych między formatami i orkiestracją procesów biznesowych. W odróżnieniu od mikroserwisów, serwisy SOA są większe i bardziej „grube", a centralny ESB jest wspólnym punktem integracji. Dominowało w enterprise w latach 2000–2015.
Enterprise Service Bus (ESB)SOAP / WSDL / XMLCentralny governanceOrkiestracja procesów (BPEL)Reużywalność serwisówWS-* standardyStandaryzowane interfejsy
Zalety i wady
✅ Zalety
✅Doskonała integracja heterogenicznych systemów i starych aplikacji legacy
✅Standaryzacja komunikacji — jeden format, jeden protokół
✅Centralne zarządzanie, monitoring i governance wszystkich integracji
✅Wsparcie dla złożonych procesów biznesowych (workflow, orkiestracja)
✅Reużywalność serwisów między różnymi systemami organizacji
❌ Wady
❌ESB jako single point of failure i bottleneck wydajnościowy
❌Ciężki overhead XML/SOAP — wolniejszy niż REST/gRPC
❌Drogi w licencjach, implementacji i utrzymaniu
❌Silny vendor lock-in (IBM WebSphere, Oracle SOA Suite)
❌Wypierany przez mikroserwisy i lekkie API-first podejście
Przykłady z życia
Systemy bankowe
Integracja core banking (np. Temenos) z kanałami: mobile, web, ATM, call center przez ESB.
Jeden z najpopularniejszych ESB-ów. Wciąż działa w tysiącach systemów enterprise.
MuleSoft
Nowoczesna platforma integracyjna wywodząca się z SOA. Przejęta przez Salesforce (2018).
SAP PI/PO
Middleware SAP łączące systemy SAP z zewnętrznymi przez standardy SOA.
💡 Kiedy stosować: Integracja heterogenicznych systemów enterprise i legacy (gdy nie można ich przepisać), organizacje z silnym centralnym governance IT, systemy finansowe i telco wymagające standaryzacji. W nowych projektach zdecydowanie prefer mikroserwisy lub API-first zamiast klasycznego SOA.
⚡ TriggerHTTP / S3 / Timer / Queue
→
λ FunkcjaBezstanowa, krótkotrwała
→
🎯 WynikDB / API / Queue / Storage
Dostawca chmury zarządza serwerami, skalowaniem i dostępnością — Ty piszesz tylko kod funkcji
W architekturze serverless deweloper pisze kod w postaci bezstanowych funkcji (Function-as-a-Service), a dostawca chmury automatycznie zarządza całą infrastrukturą — serwerami, skalowaniem, patchowaniem i dostępnością. Funkcje uruchamiane są na żądanie (triggered by event), a opłata naliczana wyłącznie za faktyczny czas wykonania (pay-per-invocation). „Serverless" nie znaczy brak serwerów — znaczy brak konieczności zarządzania nimi.
Bezstanowe funkcje (FaaS)Pay-per-executionAuto-scaling do zeraEvent triggersCold startManaged by cloudKrótki timeout (max ~15 min)
Zalety i wady
✅ Zalety
✅Zero zarządzania infrastrukturą — skupiasz się na kodzie
✅Automatyczne skalowanie od 0 do tysięcy równoległych wywołań
✅Koszt proporcjonalny do faktycznego użycia — zero płacisz za bezczynność
✅Wbudowana HA, fault tolerance i monitoring dostawcy chmury
✅Szybki development i deployment prostych workloadów
❌ Wady
❌Cold start — opóźnienie przy pierwszym wywołaniu po bezczynności
❌Vendor lock-in — kod mocno powiązany z AWS Lambda / Azure Functions
❌Ograniczony czas wykonania (Lambda: max 15 min), brak long-running tasks
❌Trudne debugowanie i testowanie lokalne
❌Kosztowne przy ciągłym, wysokim obciążeniu — taniej tradycyjny serwer
Przykłady z życia
AWS Lambda
Lider rynku. Obsługuje zdarzenia S3, API Gateway, DynamoDB, SQS. Ponad 1 bln wywołań/miesiąc.
Azure Functions
Microsoftowy FaaS. Integracje z Teams, Power Platform, Azure Event Hub.
Vercel / Netlify
Serverless functions dla frontendu — Next.js API routes, edge functions.
Google Cloud Run
Serverless containers — dowolny język, skalowanie do 0, brak cold startów jak Lambda.
Airbnb
Lambda do przetwarzania obrazów, generowania PDF i obsługi webhooków płatności.
💡 Kiedy stosować: Sporadyczne workloady (webhooks, cron jobs), event-driven processing (resize obrazu po upload na S3), proste API bez ciągłego ruchu, startupy minimalizujące koszty ops. Unikaj przy długich zadaniach, niskiej tolerancji na cold start lub wysokim, ciągłym obciążeniu.
PRODUCENCI
Serwis Zamówień
Serwis Płatności
Serwis Użytkowników
→
BROKER
📨 Event Broker
Kafka / RabbitMQ / SQS
→
KONSUMENCI
Serwis E-mail
Serwis Magazynu
Serwis Analityki
Producent nie wie nic o konsumentach — publikuje zdarzenie i jego praca się kończy
W architekturze sterowanej zdarzeniami (Event-Driven Architecture) komponenty komunikują się przez publikowanie i subskrybowanie zdarzeń (events) za pośrednictwem brokera wiadomości. Producent nie zna konsumentów — emituje zdarzenie (np. OrderPlaced) i na tym jego praca się kończy. Konsumenci reagują asynchronicznie i niezależnie. To podejście zapewnia bardzo luźne powiązanie między komponentami i naturalną skalowalność.
Miliony sensorów publikują zdarzenia temperatur, ciśnień — konsumenci reagują asynchronicznie.
💡 Kiedy stosować: Integracja mikroserwisów wymagająca luźnego powiązania, real-time event processing (IoT, logi, analytics), systemy gdzie wiele komponentów musi reagować na to samo zdarzenie (fan-out), zastąpienie synchronicznych wywołań HTTP w krytycznych ścieżkach.
📝 Komenda (Command)
↓
Write Model (Aggregate)
↓
🗃️ Event Store
Append-only · Historia zdarzeń
↓
Projekcja (Projection)
↓
🔍 Zapytanie (Query)
↓
Read Model (View / DTO)
↓
📖 Read DB (zoptymalizowany)
Redis / Elasticsearch / SQL
Write Model i Read Model to osobne modele, osobne bazy — zoptymalizowane niezależnie
CQRS (Command Query Responsibility Segregation) rozdziela modele zapisu (komendy — mutacje stanu) od modeli odczytu (zapytania — pobieranie danych). Event Sourcing idzie krok dalej — zamiast przechowywać aktualny stan obiektu, przechowuje historię wszystkich zdarzeń (events), z których stan jest każdorazowo rekonstruowany. Event Store działa jak append-only log — nigdy nie modyfikujesz, tylko dodajesz. Razem tworzą potężne, ale złożone podejście dla skomplikowanych domen biznesowych.
Osobne modele R/WEvent Store (append-only)Aggregate (DDD)Projekcje (Read Models)Command Bus / Query BusEventual consistencyTime travel (odtwarzanie stanu)Wbudowany audit log
Zalety i wady
✅ Zalety
✅Optymalizacja odczytu i zapisu osobno — różne bazy, różne indeksy
✅Pełna historia zmian — wbudowany audit log bez dodatkowej pracy
✅„Time travel" — odtworzenie stanu systemu w dowolnym momencie przeszłości
✅Doskonała skalowalność odczytu — wiele niezależnych projekcji
✅Naturalne dopasowanie do Event-Driven Architecture i mikroserwisów
❌ Wady
❌Wysoka złożoność implementacyjna — dużo więcej klas i abstrakcji
❌Eventual consistency między write i read modelem
❌Trudniejsze proste zapytania — trzeba zbudować dedykowaną projekcję
❌Duży narzut dla prostych CRUD aplikacji — overkill
❌Wymaga głębokiego rozumienia DDD i domeny biznesowej
Przykłady z życia
Systemy bankowe
Historia transakcji konta to naturalne Event Sourcing — nigdy nie edytujesz, tylko dodajesz.
E-commerce (zamówienia)
OrderCreated → PaymentReceived → Shipped → Delivered. Pełna historia jako zdarzenia.
Systemy biletowe
Każda zmiana statusu biletu / rezerwacji jako zdarzenie. Idealne do audytu i rollbacku.
Axon Framework
Najpopularniejszy framework Java/Kotlin do CQRS+ES. Używany w bankowości i ubezpieczeniach.
EventStoreDB
Dedykowana baza danych zaprojektowana specjalnie jako Event Store.
💡 Kiedy stosować: Złożone domeny biznesowe z bogatymi regułami (finanse, ubezpieczenia, e-commerce), systemy wymagające pełnego audit trail z regulacji prawnych, high-performance read/write separation, gdy potrzebujesz znać „dlaczego" a nie tylko „co" jest aktualnym stanem. Nie stosuj do prostych CRUD aplikacji — złożoność jest nieuzasadniona.