\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 írjuk meg a jövő 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 jövő héten Express.js-ben "route handler"-t írunk, az gyakorlatilag az API/Controller réteg szerepét tölti 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}