\section{Designové vzory}
Aplikace, která by měla být používaná komunitou lidí od programátorů až po koncové uživatele musí splňovat jednu důležitou vlastnost – flexibilitu. Když mluvíme o flexibilitě, myslíme tím schopnost měnit svůj vzhled, design a funkcionalitu v závislosti na požadavcích uživatelů, majitelů a případné konkurence. Tyto informace následně zužitkujeme v kapitolách \ref{subsection:architecture} a \ref{subsection:ProofOfConcept} kde na základě těchto informací budeme vytvářet aplikaci BillSaver.

Aby byla aplikace flexibilní, musí být navržená tak, aby splňovala tyto vlastnosti:

\begin{itemize}
    \item Rozšiřitelnost – Jednoduše přidávat funkcionalitu, tak aby nevznikla přílišná závislost na jiných částech aplikace.
    
    \item Udržitelnost – Schopnost upravovat, opravovat a odebírat již existující funkcionalitu, tak abychom neničili jinou funkcionalitu.
    
    \item Srozumitelnost -- Aplikace by měla být napsaná a popsaná takovým stylem, že není  pro kohokoliv problém, aby ji jednoduše, rychle a správně upravil.
    
\end{itemize}

Kvůli těmto třem vlastnostem se budeme převážně zaměřovat na designové vzory, které se dají propojit s mikroslužební architekturou. Pro podrobnější analýzu si důvody volby mikroslužební architektury rozebereme v sekci \ref{section:TechnickeAspekty}.

\subsection{MVC}
MVC je návrhový vzor, který dělí jednu službu na 3 hlavní funkční celky – model, view a controler. \cite{mvcPattern} MVC poté komunikuje přes standardní kanály mikroslužební architektury.

\begin{figure}[h]
    \centering 
    \includegraphics[width=10cm]{images/MVC_diagram.png}
    \caption{Diagram MVC architektury \cite{mvcDiagram}} 
    \label{fig:mvcModel}
\end{figure}

\subsubsection{Model}
Model obsahuje doménovou problematiku celé aplikace. Bude se tedy skládat z entit, které modelují a podporují základní problematiku, proto zůstávají vcelku neměnné. Musíme dodat, že entity v modelu o ostatních vrstvách nic nevědí.

\subsubsection{View}
View, přeloženo pohled, znázorňuje, jak budou data reprezentovaná uživateli či jinými aplikacemi. Těchto pohledů může být víc, například:

\begin{itemize}
    \item GUI pohled
    \item API pohled
    \item Logovací pohled
\end{itemize}

Představme si pohled, který vyřizuje obchodní objednávku. Obsahuje v sobě množství objednaných produktů. Tento pohled potom musí upravit počet produktů, jež patří uživateli, který kupuje dané zboží. Proto pohled potřebuje vědět o existenci modelu.

\subsubsection{Controller}
Controller dostává pokyny od uživatele nebo jiných aplikací a na jejich základě vyhodnotí a provede dané úkony. Podle změn v modelu upraví pohled a informuje uživatele. \cite{mvcPattern}

\subsection{EDA}\label{subsection:eda}
EDA neboli Event-driven architecture je architektura, která produkuje, konzumuje a reaguje na něco, čemu se říká event nebo také událost. Služby v EDA spolu komunikují přes tyto události.

\begin{figure}[h]
    \centering 
    \includegraphics[width=13cm]{images/EDA-architektura.jpg}
    \caption{Diagram EDA \cite{edaQuickQuide}} 
    \label{fig:edaModel}
\end{figure}

Událost je informace, která v sobě nese různé notifikace o změnách stavu. Události se rozdělují na tři základní typy.
\begin{itemize}
    \item Normální události – Události, které v sobě nesou informace běžné a očekávané systémem. Například – objednávka byla zaplacena.
    \item Abnormální očekávané události –  Události, které systém očekává, ale jen zřídka. Například – objednávka nebyla zaplacena.
    \item Neočekávané události – Události, na něž nedokážeme reagovat. Například – platební terminál shořel. \cite{EDAIntro}
\end{itemize}

Události se skládají ze dvou částí – hlavičky a těla.
Hlavička obsahuje informace o události, jako jsou její identifikační číslo, typ události, časová značka události a autor události. Hlavička by měla být standardizovaná napříč systémem. 

Tělo události obsahuje specifické informace o daných změnách. Události musí obsahovat všechny informace o dané události. Systémy by se neměly zpětně ptát na detailní informace. \cite{edaArchitecture}


Každá událost začíná v generátoru událostí. To může být uživatel,  jiná aplikace, senzor nebo i twitter zpráva. Generátor události ji upraví do předem definovaného standardu a nakonec ji pošle do kanálu událostí.

Kanál událostí má za úkol přenést tuto zprávu konzumentům. \cite{edaArchitecture} Často má i garantovat doručení zprávy všem konzumentům alespoň jednou, zaznamenávat zprávy, které přesouval, a nahlásit případnou chybu, když zpráva nedorazí, nebo ji konzument nepřijme. \cite{apacheKafka}

Procesor zpráv nebo také konzument má za úkol zprávu zpracovat, v případě potřeby zahájit nějakou akci nebo generovat další událost.


