Poglavlje 7: Arhitekturalni stilovi i predlošci
Priča za početak. U martu 2023. godine jedan tim u Amazonovoj službi Prime Video objavio je na svom tehničkom blogu tekst koji je odjeknuo među programerima. Tim je pravio servis koji automatski provjerava kvalitet video tokova: da li slika kasni za zvukom, da li je slika zamrznuta, da li se pojavljuju smetnje. Prva verzija napravljena je po tada najmodernijem receptu: mnogo malih, odvojenih servisa u oblaku koji jedan drugom šalju podatke, bez ijednog „pravog” servera. Kad je servis trebao provjeravati hiljade tokova, ispostavilo se da najviše novca i vremena odlazi na prenos podataka između dijelova i na usluge koje te dijelove koordiniraju, a ne na samu provjeru. Tim je sve dijelove spojio u jedan proces, i troškovi infrastrukture pali su za više od 90 %, a servis je mogao obraditi mnogo više tokova. Tekst nije tvrdio da su mikroservisi loši, i drugi dijelovi Prime Videa i dalje rade kao odvojeni servisi. Tvrdio je nešto važnije: arhitektura se bira prema problemu, a ne prema modi.
U poglavlju 6 vidjeli smo da nefunkcionalni zahtjevi DeliveryApp 2.0 (600 korisnika, izolacija gradova, novi grad bez koda) traže drugačiju strukturu sistema. Ovo poglavlje govori kako se takva struktura bira i opisuje. Prvi dio objašnjava šta je dizajn arhitekture, kako se donose i zapisuju odluke, kroz koje poglede se arhitektura gleda i koji stilovi postoje. Drugi dio opisuje aplikacijske arhitekture, troslojnu i čistu arhitekturu, i predloške (obrasce) koji se koriste unutar njih.
Literatura. Osnovna literatura predmeta:
- I. Sommerville: Software Engineering, 10th ed., Pearson, 2016 (poglavlje 6).
- L. Bass, P. Clements, R. Kazman: Software Architecture in Practice, 4th ed., Addison-Wesley, 2021.
- R. C. Martin: Clean Architecture, Prentice Hall, 2017; E. Gamma i dr.: Design Patterns, Addison-Wesley, 1994.
Riječi ovog poglavlja.
- Arhitektura softvera – osnovna struktura sistema: dijelovi, veze među njima i odluke koje se teško mijenjaju.
- Arhitekturalna odluka – izbor koji oblikuje strukturu sistema (npr. monolit ili servisi, koja baza).
- ADR (architecture decision record) – kratak zapis jedne arhitekturalne odluke: kontekst, odluka, posljedice.
- Pogled – opis arhitekture iz jednog ugla (logički, razvojni, procesni, fizički).
- C4 model – četiri nivoa dijagrama: kontekst, kontejneri, komponente, kod.
- Arhitekturalni stil – opšti način organizovanja sistema (slojevi, klijent–server, događaji, mikroservisi…).
- Monolit – aplikacija koja se gradi i isporučuje kao jedna cjelina.
- Mikroservisi – sistem od malih servisa koji se isporučuju nezavisno i razgovaraju preko mreže.
- Troslojna arhitektura – prezentacioni sloj, sloj poslovne logike i sloj podataka.
- Čista arhitektura – raspored u kojem pravila poslovanja ne zavise od baze, weba ni okvira.
- Predložak (obrazac) dizajna – provjereno rješenje za problem koji se ponavlja.
Ciljevi poglavlja. Nakon poglavlja možete: objasniti šta je arhitektura i zašto se odluke o njoj teško mijenjaju; napisati ADR; opisati poglede 4+1 i nivoe C4 modela; uporediti arhitekturalne stilove i reći kada je koji dobar; uporediti monolit, modularni monolit i mikroservise; opisati troslojnu arhitekturu; objasniti pravilo zavisnosti u čistoj arhitekturi; objasniti obrasce MVC, repozitorij, strategija, posmatrač i adapter na primjeru DeliveryApp.
Plan poglavlja – Predavanje 7: dva časa teorije i jedan čas dopunske prakse
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 7.1–7.4 Dizajn arhitekture, odluke, pogledi, stilovi | ADR: monolit ili mikroservisi za DeliveryApp 2.0? |
| Teorija 2 | 7.5–7.8 Aplikacijske arhitekture, troslojna, čista, predlošci | Repozitorij u memoriji i u SQLite-u |
| Dopunska praksa | ADR i C4 dijagram za DeliveryApp 2.0 | Dva dokumenta u docs/arhitektura |
Dio 1 – Odluke i stilovi
7.1 Šta je dizajn arhitekture
Kad se gradi kuća, neke odluke se lako mijenjaju (boja zidova, namještaj), a neke skoro nikako (broj spratova, mjesto stepeništa, temelji). Arhitektura softvera su odluke druge vrste: osnovna struktura sistema, njegovi glavni dijelovi i način na koji razgovaraju. Martin Fowler je to rekao kratko: arhitektura je ono što je teško promijeniti.
Arhitekturu najviše oblikuju nefunkcionalni zahtjevi (poglavlje 6). Gotovo svaka arhitektura može ostvariti funkcije DeliveryApp (naruči, plati, prati); razlika je u tome koliko je brza, dostupna, sigurna i laka za mijenjanje. Zato arhitekt pita: koliko korisnika, koja dostupnost, koliko timova, koliko često se isporučuje, koliko novca.
Dizajn arhitekture ima četiri koraka:
- Razumjeti pokretače: najvažnije NFR, ograničenja (budžet, tim, propisi) i funkcije.
- Predložiti strukturu: izabrati stil i podijeliti sistem na dijelove.
- Provjeriti: proći kroz scenarije kvaliteta (npr. „600 korisnika u podne”) i vidjeti da li struktura izdrži.
- Zapisati i komunicirati: dijagrami i zapisi odluka, da cijeli tim zna zašto je tako.
Ukratko.
- Arhitektura je osnovna struktura sistema i odluke koje se teško mijenjaju.
- Najviše je oblikuju nefunkcionalni zahtjevi.
- Dizajn arhitekture: razumjeti pokretače, predložiti strukturu, provjeriti scenarijima, zapisati.
7.2 Arhitekturalne odluke
Svaka arhitekturalna odluka je kompromis. Mikroservisi daju nezavisnu isporuku, ali traže mrežu, nadzor i više posla oko podataka. Keš daje brzinu, ali donosi zastarjele podatke. Ne postoji odluka bez cijene; postoji odluka čiju cijenu znamo i prihvatamo.
Zato se odluke zapisuju. Michael Nygard je 2011. predložio kratak format, ADR (architecture decision record), koji staje na jednu stranicu i čuva se u repozitoriju (docs/arhitektura/adr-001.md):
# ADR-001: DeliveryApp 2.0 kao modularni monolit
Status: prihvaćeno (sprint 1)
## Kontekst
Tim ima 6 ljudi i isporučuje svake dvije sedmice. Treba podržati 3 grada i
600 istovremenih korisnika (NZ-1a), izolaciju gradova (NZ-6) i novi grad
bez koda (NZ-7). Iskustva s mikroservisima u timu nema.
## Odluka
Jedna aplikacija (monolit) podijeljena na module s jasnim granicama:
narudžbe, dostava, plaćanje, obavještenja. Moduli razgovaraju samo preko
javnih interfejsa. Obavještenja idu preko reda poruka. Aplikacija radi u
dvije instance iza raspoređivača opterećenja.
## Posljedice
+ jedna isporuka, jednostavan nadzor, nema mrežnih poziva između modula
+ moduli se kasnije mogu izdvojiti u servise ako zatreba
- svi moduli se isporučuju zajedno
- tim mora čuvati granice modula (provjera u CI-ju)
## Razmatrane alternative
Mikroservisi od početka: odbijeno zbog veličine tima i troška rada.Vrijednost ADR-a vidi se za godinu dana, kad novi član tima pita „zašto ovo nije mikroservis?”. Odgovor je zapisan, s razlozima koji su tada važili. Ako se razlozi promijene (tim naraste na 30 ljudi), piše se novi ADR koji zamjenjuje stari.
Ukratko.
- Svaka arhitekturalna odluka je kompromis s poznatom cijenom.
- ADR zapisuje kontekst, odluku, posljedice i alternative, na jednoj stranici, u repozitoriju.
- Kad se razlozi promijene, novi ADR zamjenjuje stari.
7.3 Pogledi na arhitekturu
Plan kuće nije jedan crtež: postoji tlocrt, presjek, plan struje, plan vodovoda. Svaki odgovara na pitanja jedne struke. Isto je sa softverom.
Model 4+1 (Philippe Kruchten, 1995) opisuje arhitekturu kroz četiri pogleda i scenarije koji ih povezuju:
| Pogled | Pitanje | Za koga | UML dijagram |
|---|---|---|---|
| logički | koji pojmovi i odgovornosti postoje? | analitičari, programeri | klasni |
| razvojni | kako je kod organizovan u module i pakete? | programeri | paketa, komponenti |
| procesni | šta radi istovremeno, kako dijelovi komuniciraju u vremenu? | integratori | sekvencijalni, aktivnosti |
| fizički | na kojim mašinama šta radi? | administratori, DevOps | razmještaja |
| +1 scenariji | da li sve zajedno ostvaruje slučajeve korištenja? | svi | slučajevi korištenja |
C4 model (Simon Brown) je praktičniji za svakodnevni rad i radi kao zumiranje na mapi: od države do ulice.
- Kontekst – sistem kao jedna kutija, korisnici i vanjski sistemi oko njega.
- Kontejneri – aplikacije i baze od kojih se sistem sastoji (ne Docker kontejneri, nego „stvari koje se pokreću”).
- Komponente – dijelovi unutar jednog kontejnera.
- Kod – klase; crta se rijetko, samo za važne dijelove.
Dijagram kontejnera DeliveryApp 2.0, napisan u Mermaidu (primjeri/mermaid/s7_c4.mmd):
flowchart TB
kupac(["Kupac<br/>(mobilna aplikacija)"])
subgraph Z["DeliveryApp 2.0 (usluga u oblaku)"]
api["API narudžbi<br/>Python, FastAPI"]
dost["Komponenta dostave<br/>tarife po gradu"]
izv["Izvještaji<br/>C#, ASP.NET Core"]
red[["Red poruka"]]
baza[("Baza<br/>oznaka grada")]
end
kupac -->|"HTTPS/JSON"| api
api --> dost
api -->|"događaj"| red(Skraćeno; cijeli dijagram je na slici.)
Ukratko.
- Arhitektura se opisuje kroz više pogleda, kao kuća kroz tlocrt, presjek i instalacije.
- Model 4+1: logički, razvojni, procesni, fizički pogled i scenariji.
- C4 model zumira: kontekst, kontejneri, komponente, kod.
7.4 Arhitekturalni stilovi
Arhitekturalni stil je opšti recept za organizaciju sistema, kao što su u gradnji „prizemnica”, „neboder” ili „naselje kućica”. Najvažniji stilovi:
| Stil | Ideja | Dobar za | Primjer |
|---|---|---|---|
| slojevi | svaki sloj koristi samo sloj ispod | većinu poslovnih aplikacija | web aplikacija s logikom i bazom |
| klijent–server | klijenti traže, server odgovara | aplikacije s mnogo korisnika | mobilna aplikacija i API |
| cjevovod i filteri | podaci teku kroz niz koraka | obradu podataka, prevodioce | CI tok iz poglavlja 5 |
| događajima vođen | dijelovi objavljuju događaje, drugi reaguju | labavo povezane dijelove | „narudžba kreirana” → SMS, statistika |
| mikrokernel (dodaci) | malo jezgro + dodaci | proizvode koji se proširuju | VS Code i ekstenzije |
| mikroservisi | mali servisi, nezavisna isporuka, svaki svoja baza | velike organizacije s mnogo timova | velike platforme za video i trgovinu |
Stilovi se kombinuju. DeliveryApp 2.0 je klijent–server (aplikacija i API), unutar servera slojevit, a obavještenja su vođena događajima preko reda poruka.
Česta zabluda. „Mikroservisi su moderni, monolit je zastario.” Mikroservisi rješavaju problem organizacije: kad stotine programera u desetinama timova moraju isporučivati nezavisno. Za tim od šest ljudi donose sve troškove (mreža, nadzor, raspodijeljeni podaci, više isporuka) bez glavne koristi. Priča o Prime Videu pokazuje da i veliki timovi ponekad shvate da im za određeni problem jedan proces odgovara bolje.
Ukratko.
- Stil je opšti recept: slojevi, klijent–server, cjevovod, događaji, mikrokernel, mikroservisi.
- Stilovi se kombinuju; DeliveryApp 2.0 je klijent–server, slojevit, s događajima za obavještenja.
- Mikroservisi rješavaju problem mnogo timova; za mali tim su obično preskupi.
Provjeri se.
- Kako Fowler kratko definiše arhitekturu? – Kao ono što je teško promijeniti.
- Koja četiri dijela ima ADR? – Kontekst, odluka, posljedice i razmatrane alternative.
- Koji nivo C4 modela pokazuje aplikacije i baze sistema? – Nivo kontejnera.
Dio 2 – Aplikacijske arhitekture i predlošci
7.5 Aplikacijske arhitekture: monolit, modularni monolit, mikroservisi
Za većinu poslovnih proizvoda pitanje glasi: jedna aplikacija ili više njih?
| Monolit | Modularni monolit | Mikroservisi | |
|---|---|---|---|
| isporuka | jedna | jedna | svaki servis posebno |
| granice | često nejasne („velika kugla blata”) | jasni moduli s javnim interfejsima | mreža između servisa |
| podaci | jedna baza | jedna baza, svaki modul svoje tabele | svaki servis svoja baza |
| pogodno za | mali tim, nov proizvod | mali i srednji tim koji želi red | mnogo timova, nezavisan razvoj |
| rizik | zapetljavanje koda | disciplina granica | složenost rada i podataka |
DeliveryApp 2.0 je, prema ADR-001, modularni monolit. Ako proizvod za tri godine bude u trideset gradova sa četiri tima, modul „obavještenja” može se izdvojiti u poseban servis, jer već ima jasnu granicu i razgovara preko reda poruka.
Uz ovo, svaki proizvod ima i klijentske aplikacije: web aplikaciju u pregledniku (često kao SPA, single-page application, napisana u Reactu ili Angularu), mobilne aplikacije i tablet aplikaciju za restorane. One razgovaraju sa serverom preko API-ja (HTTP i JSON).
Ukratko.
- Monolit je jedna isporuka, modularni monolit jedna isporuka s jasnim modulima, mikroservisi više nezavisnih servisa.
- DeliveryApp 2.0 je modularni monolit, a modul se kasnije može izdvojiti u servis.
- Klijentske aplikacije razgovaraju sa serverom preko API-ja.
7.6 Troslojna arhitektura
Najčešći stil poslovnih aplikacija je troslojna arhitektura:
- Prezentacioni sloj – ono što korisnik vidi i dodiruje: ekrani mobilne aplikacije, web stranice, API rute.
- Sloj poslovne logike – pravila: obračun dostave po tarifi, prelazi stanja narudžbe, popust.
- Sloj podataka – čuvanje i čitanje: baza, repozitoriji.
Pravilo: svaki sloj razgovara samo sa slojem ispod sebe. Ekran ne čita bazu direktno; baza ne zna za ekran. Analogija je restoran: gost razgovara s konobarom (prezentacija), konobar s kuhinjom (logika), kuhinja sa skladištem (podaci). Gost ne ulazi u skladište.
Sloj se ponekad naziva i nivo (tier) kad je fizički odvojen: mobitel (prezentacija), server u oblaku (logika), poseban server baze (podaci). Riječ „sloj” (layer) je logička podjela koda, a „nivo” fizička podjela mašina.
Ukratko.
- Troslojna arhitektura: prezentacija, poslovna logika, podaci.
- Svaki sloj razgovara samo sa slojem ispod; kao gost, konobar, kuhinja i skladište.
- Sloj je logička podjela koda, a nivo fizička podjela mašina.
7.7 Čista arhitektura
Troslojna arhitektura ima jednu slabost: poslovna logika je iznad sloja podataka i zavisi od njega. Ako se promijeni baza, mijenja se i logika. A logika (pravila dostave, stanja narudžbe) je najvrednije što proizvod ima.
Čista arhitektura (Robert C. Martin, 2012, knjiga 2017) i srodna heksagonalna arhitektura („portovi i adapteri”, Alistair Cockburn, 2005) okreću smjer zavisnosti. Sistem se crta kao koncentrični krugovi:
- u centru su entiteti: pravila poslovanja (Narudžba, Tarifa);
- oko njih slučajevi korištenja: naruči, ponovi, otkaži;
- oko njih adapteri: kontroleri, repozitoriji, prezenteri;
- na obodu okviri i uređaji: web okvir, baza, servis mapa, SMS.
Pravilo zavisnosti: zavisnosti u kodu idu samo prema unutra. Unutrašnji krug ne zna ni ime ničega iz vanjskog: Tarifa ne zna da postoji FastAPI ni SQLite. Kako onda slučaj korištenja „ponovi narudžbu” čuva podatke? Tako što unutrašnji krug definiše interfejs (npr. RepozitorijNarudzbi), a vanjski krug ga implementira. To je princip inverzije zavisnosti (slovo D iz SOLID-a, poglavlje 3), primijenjen na cijelu arhitekturu.
Koristi za DeliveryApp: pravila se testiraju bez baze i weba (milisekunde, poglavlje 5); baza se može zamijeniti; isti slučajevi korištenja služe i mobilnom API-ju i C# modulu izvještaja. Cijena: više interfejsa i fajlova, što za vrlo male aplikacije nije isplativo.
Ukratko.
- Čista (i heksagonalna) arhitektura stavlja pravila poslovanja u centar.
- Pravilo zavisnosti: zavisnosti u kodu idu samo prema unutra.
- Unutrašnji krug definiše interfejse, vanjski ih implementira (inverzija zavisnosti).
- Pravila se testiraju bez baze i weba, a tehnologija se može zamijeniti.
7.8 Predlošci dizajna
Predložak (obrazac, pattern) je provjereno rješenje za problem koji se ponavlja, s imenom. Ideja dolazi od arhitekte Christophera Alexandera, koji je sedamdesetih opisao obrasce u gradnji gradova i kuća. Četvorica autora (Gamma, Helm, Johnson, Vlissides, poznati kao „banda četvorice”) objavili su 1994. knjigu Design Patterns s 23 obrasca za objektno orijentirani dizajn. Vrijednost obrasca je i u imenu: kad Amar kaže „ovdje treba adapter”, cijeli tim zna o čemu govori.
Obrasci koje DeliveryApp 2.0 koristi:
| Obrazac | Problem | U DeliveryApp 2.0 |
|---|---|---|
| MVC / MVVM | odvojiti prikaz od logike | ekrani i API (poglavlje 4) |
| Repozitorij | sakriti bazu od logike | RepozitorijNarudzbi u memoriji (testovi) i u SQLite-u (produkcija) |
| Strategija | zamjenjivo pravilo ili algoritam | tarifa grada; način plaćanja |
| Posmatrač (observer) | obavijestiti više zainteresovanih o promjeni | promjena stanja narudžbe → kupac, restoran, statistika (poglavlje 9) |
| Adapter | povezati sistem s tuđim interfejsom | adapter prema firmi za mape (rizik RZ-1) |
| Fasada | jednostavan ulaz u složen podsistem | jedna funkcija naplati() ispred sistema plaćanja |
| Posrednik (broker) | dijelovi ne znaju jedni za druge | red poruka između narudžbi i obavještenja |
Repozitorij u kodu. Servis izvještaja zavisi od interfejsa, a ne od baze (primjeri/python/repozitorij.py):
class RepozitorijNarudzbi(Protocol):
def sacuvaj(self, broj: str, grad: str, ukupno: int) -> None: ...
def ukupno_za_grad(self, grad: str) -> int: ...
def promet_grada(repo: RepozitorijNarudzbi, grad: str) -> str:
"""Servis izvještaja: radi s bilo kojim repozitorijem."""
centi = repo.ukupno_za_grad(grad)
return f"Grad {grad}: {centi // 100},{centi % 100:02d} €"Fajl ima dvije implementacije: MemorijskiRepozitorij (lista u memoriji, za testove) i SqliteRepozitorij (prava baza). Kad se u oba sačuvaju N-1001 (24,50 €, Grad A), N-2001 (25,30 €, Grad B) i N-1002 (32,00 €, Grad A), obje ispisuju „Grad A: 56,50 €”. Servis promet_grada nije promijenjen ni za slovo.
Česta zabluda. „Što više obrazaca, to bolji dizajn.” Obrazac ima cijenu (više klasa, više indirekcije) i isplati se samo kad problem zaista postoji. Kod koji ima „fabriku fabrika” za objekat koji se pravi na jednom mjestu nije dobar dizajn, nego pokazivanje.
Ukratko.
- Obrazac je imenovano, provjereno rješenje problema koji se ponavlja; GoF knjiga iz 1994. ima 23.
- DeliveryApp koristi MVC, repozitorij, strategiju, posmatrača, adapter, fasadu i posrednika.
- Repozitorij omogućava da isti servis radi s memorijom u testu i s bazom u produkciji.
- Obrazac se koristi samo kad problem postoji.
Provjeri se.
- Koja su tri sloja troslojne arhitekture? – Prezentacija, poslovna logika, podaci.
- Šta kaže pravilo zavisnosti u čistoj arhitekturi? – Zavisnosti u kodu idu samo prema unutra, prema pravilima poslovanja.
- Koji obrazac povezuje DeliveryApp s tuđim interfejsom servisa mapa? – Adapter.
Dopunska praksa – ADR i C4 za DeliveryApp 2.0
Cilj je zapisati jednu arhitekturalnu odluku i nacrtati dva nivoa C4 modela. Trajanje: jedan čas.
Korak 1 – ADR
U repozitoriju deliveryapp-2 napravite docs/arhitektura/adr-001.md po šablonu iz 7.2. Možete se složiti s odlukom iz knjige ili predložiti drugačiju, ali kontekst i posljedice moraju odgovarati vašoj odluci.
Korak 2 – Drugi ADR
Napišite adr-002.md za jednu od odluka: a) kako se obavještenja šalju (direktno ili preko reda poruka); b) gdje se čuvaju tarife gradova (kod, konfiguracioni fajl ili baza); c) koju bazu koristi DeliveryApp 2.0. Navedite bar jednu alternativu i zašto je odbijena.
Korak 3 – C4 kontekst i kontejneri
U docs/arhitektura/c4.md nacrtajte u Mermaidu:
- kontekst: DeliveryApp 2.0 kao jedna kutija, kupac, restoran, dostavljač, administrator, servis mapa, sistem plaćanja, SMS;
- kontejnere: po uzoru na
primjeri/mermaid/s7_c4.mmd, dopunjeno vašim odlukama.
Provjerite da se dijagram iscrtava na GitHubu.
Korak 4 – Repozitorij (opcionalno)
Pokrenite primjeri/python/repozitorij.py. Dodajte treću implementaciju, CsvRepozitorij, koja čuva narudžbe u CSV fajlu, i provjerite da promet_grada radi bez izmjene.
Rezultat: adr-001.md, adr-002.md i c4.md u folderu docs/arhitektura.
Vježbe
Vježba za studenta 1 – izbor stila.
Predložite stil i obrazložite: a) aplikacija koja svake noći učitava fajlove s cijenama iz pet restorana, čisti ih, preračunava i puni bazu; b) editor koda koji korisnici proširuju dodacima; c) sistem u kojem na „narudžba isporučena” reaguju obračun napojnice, statistika i anketa o zadovoljstvu.
Rješenje. a) cjevovod i filteri: podaci prolaze kroz niz koraka (učitaj → očisti → preračunaj → upiši); b) mikrokernel: malo jezgro i dodaci; c) događajima vođen stil: jedan događaj, više nezavisnih primalaca, preko reda poruka.
Vježba za studenta 2 – ADR.
Tim razmatra da obračun dostave izdvoji u poseban mikroservis „jer je to moderno”. Napišite kratke posljedice (plus i minus) i preporuku.
Rješenje. Plus: nezavisna isporuka tarifa; drugi proizvodi mogu koristiti servis. Minus: svaki obračun postaje mrežni poziv (sporije, može otkazati), treba poseban nadzor i isporuka, testovi postaju integracioni. Preporuka: zadržati dostavu kao modul (komponentu) s jasnim interfejsom unutar monolita; izdvojiti je tek kad postoji stvarna potreba, npr. drugi proizvod ili poseban tim.
Vježba za studenta 3 – čista arhitektura.
Klasa Narudzba ima liniju from fastapi import HTTPException i baca HTTPException(404) kad stavka ne postoji. Šta je narušeno i kako ispraviti?
Rješenje. Narušeno je pravilo zavisnosti: entitet u centru zavisi od web okvira na obodu. Ispravka: Narudzba baca vlastiti izuzetak (npr. StavkaNePostoji), a sloj adaptera (API ruta) ga hvata i pretvara u HTTP 404.
Vježba za studenta 4 – obrasci.
Prepoznajte obrazac: a) DeliveryApp prelazi s jedne firme za SMS na drugu, pa pravi klasu koja novi API prilagođava starom interfejsu posalji(telefon, tekst); b) kupac bira plaćanje karticom ili gotovinom, a obračun poziva nacin.naplati(iznos); c) kad narudžba promijeni stanje, obavještavaju se kupac, restoran i statistika.
Rješenje. a) adapter; b) strategija; c) posmatrač.
Sažetak u pet rečenica
- Tim Prime Videa je 2023. spojio raspodijeljene dijelove u jedan proces i smanjio troškove za više od 90 %, što pokazuje da se arhitektura bira prema problemu, a ne prema modi.
- Arhitektura je osnovna struktura i odluke koje se teško mijenjaju; oblikuju je nefunkcionalni zahtjevi, a svaka odluka je kompromis koji se zapisuje u ADR.
- Arhitektura se opisuje kroz poglede (4+1) i nivoe zumiranja (C4), a gradi od stilova kao što su slojevi, klijent–server, cjevovod, događaji, mikrokernel i mikroservisi.
- DeliveryApp 2.0 je modularni monolit u troslojnom rasporedu, a čista arhitektura okreće zavisnosti prema pravilima poslovanja, tako da pravila ne znaju za bazu i web.
- Predlošci kao što su repozitorij, strategija, posmatrač i adapter daju imena provjerenim rješenjima, i koriste se samo kad problem zaista postoji.