A lecke végére meg tudod különböztetni a réteget a szolgáltatástól, és el tudod magyarázni a rétegzés előnyét és tipikus gyengeségét.
Miért kell a rétegzés?
Egy monolit belső szerkezetének legrégebbi és legelterjedtebb szervezési módja az, hogy a kódot felelősségi szintekre osztják. Ez a szemlélet hat a későbbi stílusokra is, ezért érdemes pontosan érteni.
Mi a rétegzett architektúra?
A rétegzett architektúra a rendszert logikai rétegekre osztja, és előírja, hogy egy réteg csak az alatta levőt hívhatja. Jellemző rétegek: megjelenítés, üzleti logika, adatelérés. Az Azure Architecture Center az N-tier stílust úgy írja le, hogy minden rétegnek meghatározott felelőssége van, és a függőségeket az szabályozza, hogy egy réteg csak az alatta levő rétegeket hívhatja.
A réteg logikai fogalom (kódszerkezet), a tier fizikai (futási). Ugyanaz az alkalmazás futhat egyetlen tierben, vagy külön gépeken. A réteg tehát nem szolgáltatás, és nem jelent hálózati határt.
flowchart TB
P["Megjelenítés"] --> B["Üzleti logika"]
B --> D["Adatelérés"]
D --> DB[("Adatbázis")]
Szempontok szerint
Szempont
Rétegzett szerkezet
Csatolás
Réteghatár mentén szabályozott; a funkciók között nincs külön határ
Deployolhatóság
Jellemzően egy egység; egy változtatás több réteget érint
Skálázás
A réteg külön futtatható és skálázható, ha több tierre osztják
Adatkezelés
Jellemzően közös adatbázis
Hibakezelés
Egyszerű, mert a hívás verme egy folyamatban van
Költség
Alacsony; ismert minta
Mi a rétegzés gyengesége?
Az Azure-leírás szerint a vízszintes rétegzés megnehezítheti a változtatást: egy új funkció gyakran több rétegen is átmegy, így a változtatás egyszerre több részt érint. A réteg műszaki felelősség szerint vág (adat, logika, megjelenítés), nem üzleti felelősség szerint. Ezért a rétegzett kód sok csapat egyszerre dolgozó munkájánál ütközési ponttá válhat.
Gyakori hiba az is, hogy a rétegek „átlépik” egymást (a megjelenítés közvetlenül hív adatelérést), vagy hogy az üzleti szabályok a megjelenítésbe szivárognak. A rétegzés csak akkor ad előnyt, ha a függőségi irányt ellenőrizzük.
Hogyan viszonyul a többihez?
A rétegzett szerkezet egyszerű és ismert, de a vágás iránya (műszaki) eltér attól, amit a moduláris monolit (2.4) vagy a mikroszervizek (3.3) használnak (üzleti képesség). Egy moduláris monolit moduljain belül gyakran szintén rétegek vannak.
Gyakori tévhitek
Állítás
Pontosítás
„A három réteg három szolgáltatás.”
A réteg kódszerkezet; a tier futási szerkezet.
„A rétegzés a modulokra bontás.”
A réteg műszaki, a modul üzleti felelősség szerint vág.
„A rétegzés elavult.”
Továbbra is gyakori belső szerkezet; a gyengesége a vágás iránya, és az, hogy a monolitikus kialakítás megakadályozza a funkciók önálló kiadását.
Röviden
A rétegzett architektúra logikai rétegekre oszt, és a hívás iránya egyirányú.
A réteg kódszerkezet, a tier futási szerkezet.
A vágás műszaki felelősség szerint történik, ezért egy funkció több rétegen megy át.
Az irány betartása ellenőrzést igényel.
Ellenőrző kérdések
Miben különbözik a réteg a tiertől és a szolgáltatástól?
Miért érint egy új funkció gyakran több réteget?
Hogyan lehet ellenőrizni, hogy a rétegek nem lépik át egymást?
Rétegzett architektúra
Célok
A lecke végére meg tudod különböztetni a réteget a szolgáltatástól, és el tudod magyarázni a rétegzés előnyét és tipikus gyengeségét.
Miért kell a rétegzés?
Egy monolit belső szerkezetének legrégebbi és legelterjedtebb szervezési módja az, hogy a kódot felelősségi szintekre osztják. Ez a szemlélet hat a későbbi stílusokra is, ezért érdemes pontosan érteni.
Mi a rétegzett architektúra?
A rétegzett architektúra a rendszert logikai rétegekre osztja, és előírja, hogy egy réteg csak az alatta levőt hívhatja. Jellemző rétegek: megjelenítés, üzleti logika, adatelérés. Az Azure Architecture Center az N-tier stílust úgy írja le, hogy minden rétegnek meghatározott felelőssége van, és a függőségeket az szabályozza, hogy egy réteg csak az alatta levő rétegeket hívhatja.
A réteg logikai fogalom (kódszerkezet), a tier fizikai (futási). Ugyanaz az alkalmazás futhat egyetlen tierben, vagy külön gépeken. A réteg tehát nem szolgáltatás, és nem jelent hálózati határt.
flowchart TB P["Megjelenítés"] --> B["Üzleti logika"] B --> D["Adatelérés"] D --> DB[("Adatbázis")]Szempontok szerint
Mi a rétegzés gyengesége?
Az Azure-leírás szerint a vízszintes rétegzés megnehezítheti a változtatást: egy új funkció gyakran több rétegen is átmegy, így a változtatás egyszerre több részt érint. A réteg műszaki felelősség szerint vág (adat, logika, megjelenítés), nem üzleti felelősség szerint. Ezért a rétegzett kód sok csapat egyszerre dolgozó munkájánál ütközési ponttá válhat.
Gyakori hiba az is, hogy a rétegek „átlépik” egymást (a megjelenítés közvetlenül hív adatelérést), vagy hogy az üzleti szabályok a megjelenítésbe szivárognak. A rétegzés csak akkor ad előnyt, ha a függőségi irányt ellenőrizzük.
Hogyan viszonyul a többihez?
A rétegzett szerkezet egyszerű és ismert, de a vágás iránya (műszaki) eltér attól, amit a moduláris monolit (2.4) vagy a mikroszervizek (3.3) használnak (üzleti képesség). Egy moduláris monolit moduljain belül gyakran szintén rétegek vannak.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források