mirror of
https://github.com/kuhyx/praca_magisterska.git
synced 2026-07-04 12:03:01 +02:00
9.4 KiB
9.4 KiB
Pytanie 16: Wzorce architektoniczne
Pytanie
"Czemu służą wzorce architektoniczne? Jak powstają? Jak są katalogowane? Omówić przykładowe wzorce architektoniczne."
Przedmiot: AIS (Architektura i Integracja Systemów)
📚 Odpowiedź główna
1. Cel wzorców architektonicznych
| Cel | Opis |
|---|---|
| Reużywalność | Sprawdzone rozwiązania typowych problemów |
| Komunikacja | Wspólne słownictwo ("używamy MVC") |
| Dokumentacja | Zapis wiedzy architektonicznej |
| Jakość | Adresowanie atrybutów jakościowych |
| Edukacja | Nauka z doświadczeń innych |
2. Jak powstają wzorce
┌─────────────────────────────────────────────────────────────────┐
│ 1. PROBLEM pojawia się wielokrotnie │
│ ↓ │
│ 2. Różni architekci znajdują PODOBNE ROZWIĄZANIA │
│ ↓ │
│ 3. UOGÓLNIENIE - wyodrębnienie wspólnych elementów │
│ ↓ │
│ 4. DOKUMENTACJA w formie wzorca │
│ ↓ │
│ 5. WALIDACJA przez społeczność (peer review) │
│ ↓ │
│ 6. KATALOGOWANIE w książkach/repozytoriach │
└─────────────────────────────────────────────────────────────────┘
Format opisu wzorca:
- Nazwa - identyfikator
- Kontekst - kiedy stosować
- Problem - co rozwiązuje
- Rozwiązanie - struktura i zachowanie
- Konsekwencje - trade-offs
- Znane zastosowania - przykłady
3. Katalogowanie wzorców
| Katalog | Zakres | Przykłady |
|---|---|---|
| POSA (Pattern-Oriented Software Architecture) | Architektura | Layers, Pipes&Filters |
| GoF (Gang of Four) | Projektowe | Factory, Observer |
| EIP (Enterprise Integration Patterns) | Integracja | Message Router, Aggregator |
| PoEAA (Fowler) | Enterprise | Repository, Unit of Work |
| Cloud Patterns | Chmura | Circuit Breaker, Sidecar |
4. Przykładowe wzorce architektoniczne
Layered Architecture (Warstwy)
┌─────────────────────────────────────────┐
│ Presentation Layer │ UI, Controllers
├─────────────────────────────────────────┤
│ Business Logic Layer │ Services, Domain
├─────────────────────────────────────────┤
│ Data Access Layer │ Repositories, ORM
├─────────────────────────────────────────┤
│ Database │ SQL, NoSQL
└─────────────────────────────────────────┘
Zasada: Warstwa zna tylko warstwę bezpośrednio niższą
+ Separacja odpowiedzialności
- Sztywność, boilerplate
Microservices
┌─────┐ ┌─────┐ ┌─────┐
│User │ │Order│ │Inv- │
│Svc │ │Svc │ │entory│
└──┬──┘ └──┬──┘ └──┬──┘
│ │ │
└────┬────┴────┬────┘
│ │
┌────┴────┐ │
│API Gate │────┘
│ way │
└─────────┘
+ Niezależne wdrożenia, skalowalność
- Złożoność operacyjna, komunikacja
Event-Driven Architecture (EDA)
┌──────────┐ event ┌──────────┐
│ Producer │ ───────────→ │ Event │
└──────────┘ │ Broker │
│(Kafka) │
┌──────────┐ event └────┬─────┘
│ Consumer │ ←─────────────────┘
│ A │
└──────────┘
┌──────────┐ event
│ Consumer │ ←─────────────────┘
│ B │
└──────────┘
+ Loose coupling, skalowalność
- Eventual consistency, debugging
CQRS (Command Query Responsibility Segregation)
Commands Queries
│ │
↓ ↓
┌──────────┐ ┌──────────┐
│ Write │ │ Read │
│ Model │ │ Model │
└────┬─────┘ └────┬─────┘
│ │
↓ ↓
┌──────────┐ sync ┌──────────┐
│ Write │ ─────────→ │ Read │
│ DB │ │ DB │
└──────────┘ └──────────┘
+ Optymalizacja read/write osobno
- Złożoność, eventual consistency
Hexagonal Architecture (Ports & Adapters)
┌─────────────────────────────────────┐
│ Application Core │
│ ┌───────────────────────────────┐ │
Adapter │ │ │ │ Adapter
(REST) ──┼──│► Port Domain Port ◄├──┼── (DB)
│ │ (in) Logic (out) │ │
│ └───────────────────────────────┘ │
└─────────────────────────────────────┘
+ Testowalność, niezależność od frameworków
- Więcej kodu (adaptery)
Saga Pattern (dla transakcji rozproszonych)
Orchestration:
┌─────────┐ cmd ┌─────────┐ cmd ┌─────────┐
│ Saga │ ───────→ │ Service │ ───────→ │ Service │
│Orchestr.│ ←─reply── │ A │ ←─reply── │ B │
└─────────┘ └─────────┘ └─────────┘
│
│ compensation (rollback) jeśli błąd
↓
Choreography:
Service A ──event──→ Service B ──event──→ Service C
↑ │
└────────── compensation event ──────────┘
5. Porównanie wzorców
| Wzorzec | Skalowalność | Złożoność | Use Case |
|---|---|---|---|
| Monolith | Niska | Niska | MVP, małe zespoły |
| Layered | Średnia | Niska | Enterprise CRUD |
| Microservices | Wysoka | Wysoka | Duże systemy |
| Event-Driven | Wysoka | Średnia | Real-time, IoT |
| CQRS | Wysoka | Wysoka | Read-heavy systems |
🧠 Mnemoniki
"LAMP = Layers, API Gateway, Microservices, Pub/Sub":
Ewolucja architektur
"CQRS = Commands mutate, Queries read":
Rozdzielenie zapisu od odczytu
"Hexagonal = Inside-Out testing":
Core nie zna zewnętrznych szczegółów
❓ Pytania dodatkowe
Q1: "Kiedy wybrać monolith zamiast microservices?"
Odpowiedź: Mały zespół (<10), MVP, niejasne granice domen, brak DevOps maturity. "Monolith first" - rozdzielaj gdy wiesz gdzie granice.
Q2: "Jak CQRS współpracuje z Event Sourcing?"
Odpowiedź: Event Sourcing zapisuje zdarzenia (nie stan), CQRS buduje read model z eventów. Razem: audit trail, time-travel, ale złożoność.
Q3: "Co to jest Strangler Fig Pattern?"
Odpowiedź: Migracja z monolitu do microservices. Nowe funkcje jako mikroserwisy, stare stopniowo zastępowane. Routing przez facade. Nazwa od figi dusiciela.
🎯 Kluczowe punkty
- Wzorce = sprawdzone rozwiązania typowych problemów
- Katalogi: POSA, GoF, EIP, PoEAA
- Layered = separacja, proste, sztywne
- Microservices = niezależność, złożoność ops
- Event-Driven = loose coupling, eventual consistency
- CQRS = osobne modele read/write
📖 Źródła
- Buschmann et al. - "POSA Vol. 1"
- Fowler - "Patterns of Enterprise Application Architecture"
- Hohpe, Woolf - "Enterprise Integration Patterns"
- Richardson - "Microservices Patterns"