third week

órai anyagok/week03/sections/02-architektura.tex

@@ -0,0 +1,125 @@
+\section{Architekturális felépítések}
+
+\begin{frame}{Mi a szoftverarchitektúra, és miért számít?}
+\footnotesize
+A szoftverarchitektúra azt írja le, hogyan van a kódunk nagy egységekre (rétegekre, modulokra, szolgáltatásokra) felosztva, és ezek hogyan kommunikálnak egymással. Egy kis, egyszemélyes prototípusnál szinte mindegy, hova írjuk a kódot -- de amint a projekt nő, csapatban dolgozunk rajta, vagy hónapok múlva kell hozzányúlni, a jó architektúra dönti el, hogy karbantartható marad-e a rendszer, vagy "spagettikóddá" válik.
+
+\begin{itemize}
+\item Könnyebb megérteni: világos, hogy melyik kód mit csinál, és hol keresendő egy adott logika
+\item Könnyebb tesztelni: a rétegek külön-külön, elszigetelten tesztelhetők
+\item Könnyebb bővíteni: új funkció hozzáadásakor tudjuk, hova illesztjük be
+\item Könnyebb csapatban dolgozni: a felelősségek szét vannak választva
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Rétegzett architektúra -- az öt réteg (1/2)}
+\footnotesize
+A rétegzett felépítésnél a kódot vízszintes rétegekbe szervezzük, ahol minden réteg csak a közvetlenül alatta lévővel kommunikál. Ezen a tárgyon a következő öt réteges felosztást fogjuk következetesen használni -- elsőként a "felső" három réteg:
+
+\begin{block}{}
+\begin{itemize}
+\item \textbf{API / Controller:} fogadja a HTTP kéréseket, validálja a bemenetet, meghívja az Application réteget, visszaadja a választ -- ezt Express.js-ben már megírtuk a múlt héten
+\item \textbf{Application:} az egyes use case-eket (parancsokat/lekérdezéseket) orchesztrálja -- ide kerülnek majd a CQRS command/query handlerek
+\item \textbf{Domain:} a tiszta üzleti logika, entitások, aggregates -- semmilyen technikai függősége nincs, nem "tudja", hogy Express-ben vagy adatbázissal fut
+\end{itemize}
+\end{block}
+\end{frame}
+
+\begin{frame}{Rétegzett architektúra -- az öt réteg (2/2)}
+\footnotesize
+A maradék két réteg a rendszer "peremén" helyezkedik el: az egyik a kifelé irányuló adatszerződéseket, a másik a technikai megvalósítást fogja össze.
+
+\begin{block}{}
+\begin{itemize}
+\item \textbf{Communication:} a rétegek/külső rendszerek közti szerződések -- DTO-k, mapperek (6. hét)
+\item \textbf{Infrastructure:} a konkrét technikai megvalósítás -- adatbázis-kapcsolat, külső szolgáltatások
+\end{itemize}
+\end{block}
+
+\begin{alertblock}{Miért éri meg?}
+Ha lecseréljük az adatbázisunkat, csak az Infrastructure réteget kell módosítani -- a Domain és az API réteg változatlan marad.
+\end{alertblock}
+\end{frame}
+
+\begin{frame}{MVC minta}
+\footnotesize
+Az MVC (Model-View-Controller) a rétegzett architektúra egyik legismertebb konkrét megvalósítása, eredetileg felhasználói felületekhez, de a backend világban is elterjedt elnevezés lett a hasonló felosztásra.
+
+\begin{itemize}
+\item \textbf{Model:} az adatokat és az azokhoz tartozó szabályokat képviseli (nálunk: a Domain + Infrastructure réteg)
+\item \textbf{View:} a megjelenítés -- backend API-nál ez jellemzően a JSON válasz formázása
+\item \textbf{Controller:} fogadja a bejövő kérést, meghívja a megfelelő Model-műveletet, és visszaküldi a View-t
+\end{itemize}
+
+\begin{block}{Backend kontextusban}
+Amikor a múlt héten Express.js-ben "route handler"-t írtunk, az gyakorlatilag az API/Controller réteg szerepét töltötte be: fogadja a HTTP kérést, és delegálja a munkát az Application rétegnek.
+\end{block}
+\end{frame}
+
+\begin{frame}{Monolit vs mikroszolgáltatás}
+\footnotesize
+Ez a döntés arról szól, hogy a teljes backend rendszerünket egyetlen, összefüggő alkalmazásként (monolit), vagy sok, önállóan futtatható kis szolgáltatásra bontva (mikroszolgáltatások) építjük-e fel. Egyik sem "jobb" alapból -- a projekt méretétől és a csapat helyzetétől függ.
+
+\begin{columns}
+\begin{column}{0.48\textwidth}
+\begin{block}{Monolit}
+\begin{itemize}
+\item Egyetlen kódbázis, egyetlen futó folyamat
+\item Egyszerűbb fejleszteni és deployolni kisebb csapatban
+\item Egyszerűbb tranzakciókezelés
+\end{itemize}
+\end{block}
+\end{column}
+\begin{column}{0.48\textwidth}
+\begin{block}{Mikroszolgáltatások}
+\begin{itemize}
+\item Sok kis, önálló szolgáltatás, saját adatbázissal
+\item Külön-külön skálázhatók és deployolhatók
+\item Nagyobb komplexitás: hálózati kommunikáció, elosztott tranzakciók
+\end{itemize}
+\end{block}
+\end{column}
+\end{columns}
+
+\begin{alertblock}{Gyakorlati tanács}
+Kezdj monolittal! A tárgy során épített API is monolit lesz -- a mikroszolgáltatásokra való szétbontás egy már működő, jól rétegzett monolitból sokkal könnyebb, mint elölről tervezni.
+\end{alertblock}
+\end{frame}
+
+\begin{frame}{Separation of Concerns}
+\footnotesize
+A "Separation of Concerns" (felelősségek szétválasztása) az az elv, ami az összes eddigi mintát (rétegzés, MVC) megalapozza: minden kódegységnek egyetlen, jól körülhatárolt felelőssége legyen.
+
+\begin{itemize}
+\item Egy függvény/osztály ne csinálja egyszerre a HTTP kérés kezelését \emph{és} az adatbázis-lekérdezést \emph{és} az email küldést
+\item Ha egy dolog megváltozik (pl. az adatbázis lekérdezésének módja), az csak egy helyen igényeljen módosítást
+\item Könnyebb egyesével, elszigetelten tesztelni az egyes felelősségeket
+\end{itemize}
+
+\begin{block}{Ökölszabály}
+Ha egy függvény nevét csak "és"-sel tudod leírni (pl. "validál ÉS ment ÉS emailt küld"), valószínűleg érdemes szétbontani.
+\end{block}
+\end{frame}
+
+\begin{frame}{Kitekintés -- mi jön még ebben a témában}
+\footnotesize
+A rétegzett architektúra és a Separation of Concerns elve két fogalmat is megalapoz, amikkel a félév további részében részletesen foglalkozunk majd -- most csak annyit érdemes megjegyezni, hogy hova illeszkednek.
+
+\begin{itemize}
+\item \textbf{Repositories és Aggregates (5. hét):} az Infrastructure réteg formalizált, ORM-alapú megvalósítása -- a repository "elrejti" az adatbázis-lekérdezéseket egy egyszerű interfész mögé
+\item \textbf{Dependency Injection (11. hét):} technika arra, hogy a rétegek közötti függéseket (pl. "a controllernek szüksége van a service-re") ne kézzel drótozzuk be, hanem egy keretrendszer intézze
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Összefoglalás -- Architekturális felépítések}
+\footnotesize
+\begin{block}{Architektúra}
+\begin{itemize}
+\item A jó architektúra karbantarthatóvá, tesztelhetővé és bővíthetővé teszi a rendszert
+\item Rétegzett architektúra (öt réteg): API/Controller -- Application -- Domain -- Communication -- Infrastructure
+\item MVC: Model-View-Controller -- a Controller felel meg a jövő heti Express.js route handlernek
+\item Monolit vs mikroszolgáltatás: kezdj monolittal, bontsd szét később, ha indokolt
+\item Separation of Concerns: minden kódegységnek egy jól körülhatárolt felelőssége legyen
+\end{itemize}
+\end{block}
+\end{frame}