\chapter{Technické řešení}
\section{Architektura}\label{subsection:architecture}
Pro správné fungování celého projektu je kritický prvotní návrh systému, tedy správné rozdělení buisness entit, navržení komunikace a popis zodpovědnosti.

Ze zadání nám vychází, že existují dvě skupiny uživatelů – obchodníci a spotřebitelé. Pro pochopení si všechny potřeby obou skupin zapíšeme do tabulky.

\begin{table}[h]
\centering
\begin{tabular}{|cc|}
\hline
\multicolumn{2}{|c|}{Potřeby uživatelů}                                                                                        \\ \hline
\multicolumn{1}{|c|}{Obchodníci}                                                     & Spotřebitelé                           \\ \hline\hline
\multicolumn{1}{|c|}{Informativní UI}                                                & Jednoduché a intuitivní UI              \\ \hline
\multicolumn{1}{|c|}{Souhrnný přehled demografických charakteristik svých zákazníků}  & Informovaný náhled nad svými útratami   \\ \hline
\multicolumn{1}{|c|}{Snadná integrace s již existujícími systémy}                    & Podpora většiny uživatelských zařízení \\ \hline
\multicolumn{1}{|c|}{Zabezpečení prodejních dat, tedy převážně účtenky}              & Zabezpečení svých osobních dat          \\ \hline
\multicolumn{2}{|c|}{Podpora všech buisness funkcionalit, které byly stanoveny v kapitole \ref{subsection:FinalniStav}}         \\ \hline
\multicolumn{2}{|c|}{Přidávat další funkcionalitu na základě požadavků}                                                        \\ \hline
\multicolumn{2}{|c|}{Aplikace musí být dostupná}                                                                               \\ \hline
\end{tabular}
\caption{Porovnaní potřeb spotřebitelů a obchodníků}
\label{table:architectureNesesity}
\end{table}

Z těchto potřeb nám vyplynulo několik nutných aspektů, které musí naše architektura podporovat: 
\begin{itemize}
\item Flexibilita – Pro uspokojení obou skupin uživatelů musí být náš systém flexibilní pro případné změny nebo doplňky funkcionality. 
\item Škálovatelnost – Abychom se nedostali do komplikací při nákupních horečkách, například Black Friday či Cyber Monday,  musíme být schopni přidat více výpočetních výkonů, abychom nekolabovali pod nátlakem uživatelů a účtenek.
\item Robustnost – V případě výpadku  nebo plánované odstávky bychom neměli přestat přijímat účtenky od obchodníků. Obchodníci i uživatelé by se měli spolehnout na to, že jejich data budou v bezpečí a neztratí se.
\end{itemize}

Kvůli těmto potřebám se nejlépe hodí použití mikroservisní architektury. Z toho vyplývá, že musíme klást velký důraz na návrh buisness entit, jednotného komunikačního standardu a ohraničení jednotlivých odpovědností.

\section{Buisness služby}
V této kapitole si rozepíšeme jednotlivé buisness služby, jež figurují v systému, a ohraničíme jejich odpovědnosti. Na tyto služby následně navazuje obrázek \ref{fig:BillSaverArchitecture} který ukazuje primární komunikační cesty které systém bude používat.

\begin{enumerate}
    \item Spravce účtenek: První buisness služba je určitě úložiště účtenek. Má za úkol přijímat účtenky ve správném formátu 
a ukládat je. Při přijetí účtenky odešle notifikaci, že danému uživateli přišla účtenka. V případě dotazu na účtenky služba  požadované účtenky vrátí. 
    
    \item Správce Zboží: Další služba uchovává data o daných produktech. Poslouchá, jestli nepřišly nové účtenky, 
a pokud ano, vyextrahuje produkty, které přišly, zkontroluje, že daný produkt zná a má všechna jeho potřebná data. Pokud by nějaká data chyběla, vyšle žádost o doplnění informací. Dále poskytuje informace o daných produktech na základě dotazů od uživatelů. 

    \item Generátor účtenek: Třetí služba propojuje systém obchodníka se systémem BillSaver. Upraví účtenku do podoby podporované BillSaverem a následně ji odešle dál.
    
    \item Správce spotřebitelských účtů: Služba, která má na starosti uživatelská data, je vstupním bodem pro spotřebitele. Má na starosti uživatelskou registraci, úpravu uživatelských dat a propojování platebních metod s účtenkami.
    
    \item Spotřebitelský informační systém: Spotřebitel bude pravidelně komunikovat s informační entitou, jež má na starosti monitorování správy ohledně účtenek a správy od obchodníků. Uživatel bude moct hodnotit své nákupy a případně posílat připomínky obchodníkům.
    
    \item Spotřebitelské rozhraní: Toto rozhraní zajišťuje synchronní komunikaci se všemi systémy se kterými musí spotřebitel komunikovat.
    
    \item Správce obchodních účtů: Stejně jako služba, která propojovala spotřebitele, existuje i služba propojující obchodníky s BillSaverem. Má na starosti registraci a úpravu obchodníkových dat.
    
    \item Obchodní informační systém: Pro obchodníky existuje separátní informační služba, jež  sbírá zpětnou vazbu od uživatelů, shromažďuje jejich reakce na jednotlivé produkty a informuje o dotazech k doplnění informací. Dále monitoruje případné dotazy k doplnění informací o daných produktech. Pokud takový dotaz přijde a bude se týkat daného obchodníka, obchodníkovi přijde zpráva o doplnění informací o daném produktu. Až obchodník doplní informace o zboží, služba odešle požadavek na úpravu informací o daném produktu.
    
    \item Obchodní rozhraní: Toto rozhraní zajišťuje synchronní komunikaci se všemi systémy se kterými musí obchodník komunikovat.
    
    \item Notifikační služba: Notifikační služba sleduje žádosti o poslání notifikací jak spotřebiteli, tak obchodníkovi a na základě jejich nastavení je informuje v uživatelsky nastavené frekvenci buď posíláním notifikací do mobilu, e-mailem či bude posílat informace zprávami SMS.
    
    \item Vyhodnocovací systém: Vyhodnocovací systém má na starosti vyhodnocování uživatelských nákupních trendů a na jejich základě vytváří prediktivní uživatelské modely, jež doporučují spotřebiteli zefektivnění jeho nákupních zvyků.
\end{enumerate}

\begin{figure}[h]
    \centering 
    \includegraphics[width=17 cm]{images/High-Level Architecture.png}
    \caption{Návrh jednotlivých mikroservisních služeb a jejich primární komunikační cesty} 
    \label{fig:BillSaverArchitecture}
\end{figure}

K těmto službám přibudou ještě dvě důležité služby, které nemají nic společného s buisness kontextem aplikace, ale jsou určitě velice nutné ke správnému fungování celého systému. 
\begin{itemize}
    \item Logování: Tato služba bude poslouchat všechny ostatní služby a bude zapisovat všechno, co ostatní služby pošlou a co bude jejich log. To bude sloužit k identifikování případných chyb a zajistí nám tak rychlejší řešení problémů v budoucnu. V této službě se budou skladovat úplně všechny logy vygenerované během činnosti systému, tedy auditní logy, server logy, logy přijatých zpráv a popřípadě i další.
    \item Monitorování: Tato služba bude mít za úkol sledování stavu celého systému, tedy monitorování zatíženosti systému, sledování, jestli jednotlivé služby jsou funkční, a případně bude informovat admin tým ohledně problémů.
\end{itemize}



\section{Data}
V této kapitole se zaměříme na vydefinování důležitých dat, která musí jednotlivé služby uchovávat a odesílat.

Hlavní data uchovávaná v BillSaveru  jsou účtenky. Tyto informace můžeme rozdělit na hlavičky a  těla. Hlavička obsahuje všechny identifikační údaje o dané tržbě a celkovou cenu, tělo obsahuje a cenu jednotlivých produktů spolu s jejich identifikačními parametry. Pro detailní informace, jaká data se ukládají a přenášejí, si vypíšeme v tabulkách: \ref{table:dataHlavicka}, \ref{table:dataTelo}, \ref{table:dataSazba}, \ref{table:dataProdukt}. Všechny tyto informace jsou vcelku neměnné, a proto tyto informace ukládáme v relační databázi.

Důležitá jsou dále data jednotlivého zboží, která jsou definované číslem EAN. Protože se mohou tyto informace hodně lišit, ukládáme je v dokumentové databázi pro její jednoduchou expadibilitu pro více informací, viz: \ref{subsection:documentDatabases}. Tyto informace se vydefinují s jednotlivými obchodníky. Pro obrovskou variabilitu si zde ukážeme možné hodnoty pro dva typy zboží: jídlo a mobilní telefony. Viz tabulky \ref{table:dataJidlo}, \ref{table:dataElektro}.

Poslední, co uchováváme, jsou osobní data obchodníků a uživatelů. Ty zde nebudeme rozepisovat pro jejich relativně jednoduchou strukturu, pouze si zde vypíšeme ty důležité. Spotřebitel: jméno, příjmení, heslo, kontaktní údaje, připojené kreditní a debetní karty. Obchodník: název společnosti, identifikační údaje jednotlivých poboček, údaje o společnosti pro finanční úřad jako IČO, DIČ a podobně a kontaktní udaje.


\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.19\linewidth}|>{\hspace{0pt}}m{0.4\linewidth}|>{\hspace{0pt}}m{0.15\linewidth}|>{\hspace{0pt}}m{0.19\linewidth}|} 
\hline
\multicolumn{4}{|>{\centering\arraybackslash\hspace{0pt}}m{0.936\linewidth}|}{Hlavička}\\ 
\hline
Název           & Popis                                                                                                                                                                                                                                                                   & Povinnost                    & Datový typ v Java  \\ 
\hline\hline
UUID obchodníka & Zpráva definující, od koho účtenka přišla, systém poté spáruje UUID obchodníka s jeho účtem. IČO, DIČ a jiné identifikátory si bude moct obchodník nastavovat v jeho účtu.                                                                                               & Ano                          & UUID               \\ 
\hline
UUID provozovny & Zpráva definující, z jakého obchodu účtenka přišla. Účtenka se poté spáruje s názvem, adresou a nebo telefoním číslem specifické provozovny. Stejně jako u UUID obchodníka i u UUID provozovny si bude moct obchodník nastavit různé parametry ve svém systému.   & Ano                 & UUID               \\ 
\hline
Datum tržby     & Datum a specifický čas, kdy obchodník zaznamenal tržbu.                                                                                                                                                                                                                  & Ano                          & LocalDateTime      \\ 
\hline
ID Pokladny     & Označení pokladního zařízení, na kterém je tržba evidována.                                                                                                                                                                                                             & Ano                          & String             \\ 
\hline
Číslo účtenky   & Pořadové číslo účtenky zaznamenané pokladním systémem.                                                                                                                                                                                                                  & Ano                          & String             \\ 
\hline
Režim tržby     & Termín stanovující zákon, obchodník může uvést buď „běžný", nebo „zjednodušený".                                                                                                                                                                                           & Ano                          & String             \\ 
\hline
FIK             & Fiskální identifikační kód vygenerovaný finanční správou.                                                                                                                                                                                                               & Ne                           & String             \\ 
\hline
PKP             & Podpisový kód poplatníka vygenerovaný pokladním zařízením.                                                                                                                                                                                                              & Záleží na režimu tržby a FIK & String             \\ 
\hline
BKP             & Bezpečnostní kód poplatníka vygenerovaný z PKP                                                                                                                                                                                                                          & Ano                          & String             \\
\hline
\end{tabular}
\caption{Informace v hlavičce účtenky}
\label{table:dataHlavicka}
\end{table}

\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.19\linewidth}|>{\hspace{0pt}}m{0.4\linewidth}|>{\hspace{0pt}}m{0.15\linewidth}|>{\hspace{0pt}}m{0.19\linewidth}|} 
\hline
\multicolumn{4}{|>{\centering\arraybackslash\hspace{0pt}}m{0.936\linewidth}|}{Tělo}                                        \\ 
\hline
Název          & Popis                                                                        & Povinnost & Datový typ v Java  \\ 
\hline
Celková cena   & Celková cena tržby včetně DPH                                                & Ano       & BigDecimal         \\ 
\hline
Sumární sazba  & Seznam jednotlivých sazeb DPH spolu se základem daně, samotnou daní a celkovou cenou & Ano       & List<Sazba>          \\ 
\hline
Seznam položek & Seznam produktů, které spotřebitel nakoupil                                   & Ano       & List<Produkt>        \\
\hline
\end{tabular}
\caption{Informace v tělu účtenky}
\label{table:dataTelo}
\end{table}

\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.19\linewidth}|>{\hspace{0pt}}m{0.4\linewidth}|>{\hspace{0pt}}m{0.15\linewidth}|>{\hspace{0pt}}m{0.19\linewidth}|} 
\hline
\multicolumn{4}{|>{\centering\arraybackslash\hspace{0pt}}m{0.936\linewidth}|}{Sazba}             \\ 
\hline
Název       & Popis                                             & Povinnost & Datový typ v Java  \\ 
\hline
Sazba daně  & Procentuální sazba daně                           & Ano       & BigDecimal         \\ 
\hline
Základ daně & Základ daně všech produktů zahrnutých v sazbě DPH & Ano       & BigDecimal         \\ 
\hline
Daň         & Daň vypočítaná ze sazby daně a základu daně       & Ano       & BigDecimal         \\ 
\hline
Celkem      & Celková částka sečtená z daně a základu daně      & Ano       & BigDecimal         \\
\hline
\end{tabular}
\caption{Informace o sazbě}
\label{table:dataSazba}
\end{table}

\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.19\linewidth}|>{\hspace{0pt}}m{0.4\linewidth}|>{\hspace{0pt}}m{0.15\linewidth}|>{\hspace{0pt}}m{0.19\linewidth}|} 
\hline
\multicolumn{4}{|>{\centering\arraybackslash\hspace{0pt}}m{0.937\linewidth}|}{Produkt}          \\ 
\hline
Název      & Popis                                             & Povinnost & Datový typ v Java  \\ 
\hline
EAN        & European Article Number položky neboli čárový kód & Ano       & String             \\ 
\hline
Sazba daně & Procentuální sazba daně, do které položka spadá    & Ano       & BigDecimal         \\ 
\hline
Cena       & Celková cena daného produktu                      & Ano       & BigDecimal         \\ 
\hline
Množství   & Celkové množství jedné položky                    & Ano       & BigDecimal         \\ 
\hline
Jednotka   & Jednotka množství, tedy kg, kus, litr atd.        & Ano       & Enum               \\
\hline
\end{tabular}
\caption{Informace o produktech v účtence}
\label{table:dataProdukt}
\end{table}

\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.19\linewidth}|>{\hspace{0pt}}m{0.4\linewidth}|>{\hspace{0pt}}m{0.15\linewidth}|>{\hspace{0pt}}m{0.19\linewidth}|} 
\hline
\multicolumn{4}{|>{\centering\arraybackslash\hspace{0pt}}m{0.936\linewidth}|}{Jídlo}                         \\ 
\hline
Název            & Popis                                                  & Povinnost & Datový typ v Java    \\ 
\hline
EAN              & European Article Number položky neboli čárový kód      & Ano       & String               \\ 
\hline
Název            & Název zboží                                            & Ano       & String               \\ 
\hline
Výrobce          & Výrobce produktu                                       & Ano       & String               \\ 
\hline
Země původu      & Země, kde bylo zboží vyrobeno nebo vypěstováno          & Ano       & String               \\ 
\hline
Kalorie          & Počet kalorií v suchém / nepřipraveném stavu           & Ano       & BigDecimal           \\ 
\hline
Popis            & Popis produktu vytištěný na obalu či příbalovém letáku & Ne        & String               \\ 
\hline
Složení          & Složení produktu                                       & Ne        & String               \\ 
\hline
Nutriční hodnoty & Tabulka s nutričními hodnotami                         & Ne        & List<Nutriční Hodnota>  \\
\hline
\end{tabular}
\caption{Informace o produktu: Jídlo}
\label{table:dataJidlo}
\end{table}

\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.19\linewidth}|>{\hspace{0pt}}m{0.4\linewidth}|>{\hspace{0pt}}m{0.15\linewidth}|>{\hspace{0pt}}m{0.19\linewidth}|} 
\hline
\multicolumn{4}{|>{\centering\arraybackslash\hspace{0pt}}m{0.936\linewidth}|}{Elektronika}                                             \\ 
\hline
Název       & Popis                                                                                   & Povinnost & Datový typ v Java  \\ 
\hline
EAN         & European Article Number položky neboli čárový kód                                       & Ano       & String             \\ 
\hline
Název       & Název zboží                                                                             & Ano       & String             \\ 
\hline
Výrobce     & Výrobce produktu                                                                       & Ano       & String             \\ 
\hline
Země původu & Země, kde bylo zboží vyrobeno.                                                                 & Ano       & String             \\ 
\hline
Popis       & Popis produktu vytištěný na obalu či příbalovém letáku                                  & Ne        & String             \\ 
\hline
Specifikace & Specifikace zboží. Například: rozlišení obrazovky, velikost úložiště, velikost baterie. & Ano       & List<Specifikum>      \\ 
\hline
Manuál      & Odkaz na soubor s manuálem                                                              & Ano       & String             \\
\hline
\end{tabular}
\caption{Informace o produktu: Elektronika}
\label{table:dataElektro}
\end{table}

\section{Komunikace}
Škálovatelná a jednotná komunikace napomůže k udržení flexibility a robustnosti jednotlivých služeb. Abychom však dokázali komunikaci udržet jednotnou a škálovatelnou, musíme vybrat standardní technologii, která se bude používat napříč všemi službami. Existují dva typy komunikace pro mikroslužbovou architekturu, synchronní a asynchronní.

Synchronní komunikace funguje na principu odeslání žádosti a čekání na odpověď. Tato odpověď může být jak kladná, tedy vrátila se správná data, tak záporná, tzn. něco se pokazilo na serveru. Synchronní komunikace se většinou používá na takovou komunikaci, kde je odpověď vyžadovaná okamžitě. Takováto komunikace se většinou vyžaduje 
u interakce s uživatelem, jenž chce informace dostat okamžitě na svůj dotaz. Nejznámější technologie, které na takovouto komunikaci existují, jsou REST, SOAP, GraphqQL a gRPC. Každá z nich má své výhody a nevýhody. Zde si je porovnáme a na základě výsledku vybereme tu nejvhodnější technologii pro synchronní komunikaci.

\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.111\linewidth}|>{\hspace{0pt}}m{0.196\linewidth}|>{\hspace{0pt}}m{0.188\linewidth}|>{\hspace{0pt}}m{0.182\linewidth}|>{\hspace{0pt}}m{0.257\linewidth}|} 
\hline
                            & \multicolumn{4}{>{\centering\arraybackslash\hspace{0pt}}m{0.823\linewidth}|}{Synchroni komunikace}                                                                                                                                                \\ 
\hline
                            & REST                                                    & Soap                                                  & GraphQL                                             & gRPC                 \\ 
\hline
Popularita                  & Velká                                                   & Malá                                                  & Střední                                             & Střední                                                                   \\ 
\hline
Jednoduchost použití        & Velice jednoduché                                       & Jednoduché                                            & Středně těžké                                       & Středně těžké                                                            \\ 
\hline
Rychlost komunikace         & Střední                                                 & Střední                                               & Pomalá                                              & Rychlá                                                                    \\ 
\hline
Podpora v aplikačních rámcích & Velká                                                 & Střední                                               & Malá                                                & Střední                                                                   \\ 
\hline
Výhody:                     & Rozhraní používané v celém webu.                         & Rozhraní, které je stále používáno ve finančním sektoru & Klient si dokáže vybrat data, která mu server pošle & Velice rychlá komunikace                                                  \\ 
\hline
                            & Velká znalost ve vývojářské komunitě                    & Podpora starších systémů                              & Vysoká míra flexibility pro uživatelské rozhraní    & Obousměrná komunikace založená na HTTP/2                                 \\ 
\hline
                            & Jednoduché nastavení ukládání do mezipaměti             & Značné rozšíření pro zabezpečení komunikace            & Není potřeba verzovat rozhraní                      &                                                                           \\ 
\hline
Nevýhody:                   & Neexistuje jeden správný způsob, jak vytvářet rest api   & Podpora pouze XML formátu                             & Při množství dotazů můžeme přetížit službu         & Vysoká provázanost mezi službami                                          \\ 
\hline
                            & Velké množství obecných dat, jako jsou odkazy na jiné api & Vysoká režie                                          & Velice obtížné nastavení ukládání do mezipaměti     & Dokumentace musí být psaná zvlášť, neexistuje žádná introspekce rozhraní  \\
\hline
\end{tabular}
\caption{Tabulka porovnávající jednotlivé komunikační standardy \cite{synchronusComparison1, synchronusComparison2, synchronusComparison3}}
\label{table:dataSynchronusComunication}
\end{table}

Kvůli velké rozšířenosti a vysoké podpoře v aplikačních rámcích vybereme REST rozhraní k synchronní komunikaci. Velké transfery dat budou zajišťovat asynchronní volání, kvůli tomu nepotřebujeme benefity gRPC. Dále i když by graphQL byla vhodnější volba, její nízká rozšířenost a komplexní zavedení do jednotlivých systémů ji diskvalifikuje z výběru. Nakonec výhody soap rozhraní rychle zastíní jeho vysoká režie a tím pádem pomalá komunikace oproti REST.

Asynchroní komunikace funguje na principu odeslání zprávy, která obsahuje fakt  nebo instrukci. Tato zpráva se za nějakou dobu zpracuje, ale služba, jež ji odeslala, nečeká na odpověď. Služby na sebe nejsou vůbec vázané a systém se kvůli tomu stává jednoduše škálovatelným, flexibilním a robustním.  Proto se pokusíme najít nejrychlejší technologii pro posílání dat.  Takováto komunikace bude v našem systému používaná pro přenos a zpracování velkého množství dat. Kvůli tomu se pokusíme najít nejrychlejší technologii pro takovouto asynchronní komunikaci.

Základní technologie, které se používají pro přenos asynchronních dat, jsou RabbitMQ, Pulsar a Kafka. Jak můžeme vidět na obrázku \ref{fig:asynchronousPerformance}, rychlost Kafky je 2× větší než Pulsar a 10× větší než RabbitMQ. Díky těmto výsledkům je jisté, že pro asynchronní komunikaci použijeme technologii Kafka.

\begin{figure}[h]
    \centering 
    \includegraphics[width=15cm]{images/throughput-and-latency-quantiles.png}
    \caption{Porovnání rychlostí jednotlivých asynchronních technologií \cite{asynchronousPerformance}} 
    \label{fig:asynchronousPerformance}
\end{figure}

\section{Základní technologie}
Jak jsme již rozebrali v kapitole \ref{section:aplicationFrameworks}, nejpopulárnější aplikační rámce jsou Spring Boot a Quarkus. Kvůli široké dokumentaci a daleko větší popularitě vybereme pro náš projekt Spring Boot. Díky této volbě a kvůli tomu, že chceme používat standardní technologie, se nám automaticky zúží výběr pomocných aplikačních rámců.

Java spolu se Spring Boot stále potřebují JVM pro běh celé aplikace. Běh těchto aplikací zajišťuje Java servlet container, což je aplikační server, který v sobě spouští Java EE aplikace, tedy Spring Boot aplikace. Základní server, který Spring Boot používá, se jmenuje Tomcat.

Spring Boot používá pro komunikaci s DBMS Spring data JPA, který vnitřně používá Spring Data a Hibernate pro komunikaci s databázemi.

Pro REST, tedy synchronní komunikaci Spring Boot, využívá Spring WebFlux. WebFlux vytváří jednoduché REST rozhraní s automatickou dokumentací koncových bodů. 

Pro asynchronní komunikaci Spring Boot obsahuje Spring for Apache Kafka. Toto rozšíření přidává celému projektu jednoduché použití Kafky. Dále existuje 
i modul Spring Cloud Stream, který přidává stream processing do našeho systému.

Abychom vytvářeli jednoduchý a přehledný kód, využíváme autogeneraci kódu od projektu Lombook, a abychom psali ještě méně kódů v případě potřeby konverze jednoho objektu do jiného, využíváme Mapstruct projekt, který automaticky vytváří konverzní funkce.

Spring Boot také obsahuje automatické testovací rozhraní pro náš kód. K tomu využívá Spring Test, který obsahuje testování jak jednotlivých funkcí (unit testing), tak aplikačního rozhraní (intergation testing). Pro unit testing využívá knihovnu Juint 5.

Pro rekapitulaci uvedeme tabulku \ref{table:zakladniTechnologie}, kde sjednotíme všechny základní technologie, které naše služby využívají.



\section{CI/CD}\label{subsection:ci/cd}
CI/CD se zaměřují na zautomatizování procesů potřebných k nasazení jednotlivých služeb do produkčního prostředí. Použití tohoto procesu nám umožní rychleji odhalovat chyby, zvýšit kvalitu kódu a svým zaměřením se velmi hodí pro použití SCRUM modelu vývoje.

Protože používáme Intellij IDEA se vzdálenou kompilací odůvodnění, viz: \ref{section:TechnickeAspekty}, využijeme 
i ostatní produkty od Jetbrains. Budeme tak mít jednotné prostředí, které spolu velice dobře komunikuje a operuje. 

Tedy pro automatické testování, kompilaci, sledování problému, správu celého projektu využijeme Space od Jetbrains.

Pro běh jednotlivých služeb na produkčním serveru použijeme standardní virtualizační technologii Kubernetes. Tato technologie zajistí jednoduché škálování, automatické monitorování aplikací a jednoduchou migraci celé služby na jiné fyzické servery buď lokální, nebo k poskytovateli cloud computing služeb.


\begin{table}
\centering
\begin{tabular}{|>{\hspace{0pt}}m{0.213\linewidth}|>{\hspace{0pt}}m{0.198\linewidth}|>{\hspace{0pt}}m{0.528\linewidth}|} 
\hline
\multicolumn{3}{|>{\centering\arraybackslash\hspace{0pt}}m{0.939\linewidth}|}{Použité technologie}               \\ 
\hline
Název technologie       & Oblast použití     & Popis                                                             \\ 
\hline
Java                    & Základ             & Výchozí programovací jazyk                                        \\ 
\hline
Spring Boot             & Základ             & Základní aplikační rámec, který propojuje ostatní aplikační rámce  \\ 
\hline
Tomcat                  & Základ             & Výchozí Java servlet container                                    \\ 
\hline
Spring Data             & Komunikace         & Zajišťuje komunikaci s DBMS                                       \\ 
\hline
Hibernate               & Komunikace         & Zajišťuje transformaci DBMS objektu do Java entit                 \\ 
\hline
Spring WebFlux          & Komunikace         & Zajišťuje vytváření a komunikaci přes standardní REST rozhraní    \\ 
\hline
Spring for Apache Kafka & Komunikace         & Zajišťuje asynchronní komunikaci s ostatními službami              \\ 
\hline
Lombook                 & Přehlednost kódu   & Auto-generuje kód ze základních anotací                            \\ 
\hline
Mapstruct               & Přehlednost kódu   & Auto-generuje transformační funkce mezi objekty                  \\ 
\hline
Spring Test             & Testování          & Zjednodušuje vytváření jak unit, tak integration testů             \\ 
\hline
Junit 5                 & Testovaní          & Využívá se k testování jednotlivých funkcí.                        \\ 
\hline
Git                     & DevOps             & Správce souborů a verbovací nástroj pro kód                       \\ 
\hline
Space                   & DevOps, Management & Tvorba a udržování CI/CD a management celého projektu              \\
\hline
\end{tabular}
    \caption{Použité základní technologie v projektu} 
    \label{table:zakladniTechnologie}
\end{table}

\section{Procesní flow}
V teto sekci se zaměříme na popis důležitých procesů, které v systému probíhají. Jde především o uložení účtenek, verifikaci dat, přidání platební karty, přidání a úpravu zboží. Zobrazení dat, účtenky, uživatelské informace zde nebudeme ukazovat, bude se jednat o jednoduché volání do databáze.

\subsection{Uložení účtenky}

\begin{enumerate}
    \item Obchodník přijde do obchodu, nakoupí a začne platební proces. Pokladní systém zpracuje všechny položky, které nakoupil, a vytvoří platební příkaz. V tomto procesu vygeneruje veškeré náležité údaje, které patří k účtence, jako jsou FIK, datum a čas nákupu a ostatní identifikační čísla. Jakmile uživatel zaplatí, pokladní systém pošle číslo karty generátoru účtenek.
    
    \item Generátor účtenek zaheshuje tato data a zkontroluje v jeho interní databázi zaheshovaných karetních údajů, jestli systém může přijmout tuto účtenku, která byla zaplacena poskytnutou kartou. Generátor účtenek tedy vrátí pokladnímu systému true/false.
    
    \item Pokud pokladní systém dostane zpět false, pokračuje starým způsobem. V případě, že dostane true, pošle účtenku generátoru účtenek. Následně řekne spotřebiteli, že účtenku najde ve svém BillSaver účtu.
    
    \item Generátor převede účtenku po přijetí do standardního tvaru. Číslo karty zaheshuje, podepíše účtenku obchodním privátním klíčem a odešle ji přes Kafku do streamu neověřených účtenek.
    
    \item Správce obchodníka přijme tuto účtenku, ověří její podpis a pošle ji do streamu ověřených účtenek.
    
    \item Správce uživatelských účtů přijme ověřenou účtenku a přiřadí k ní uživatele na základě zaheshovanych karetních údajů. Následně účtenku pošle do streamu přiřazených účtenek. 
    
    \item Správce zboží přijme, ověřenou a přiřazenou účtenku si uloží a odešle zprávu, že uživateli byla přidána nová účtenka.
    
\end{enumerate}

\subsection{Přidání platební karty}

\begin{enumerate}
    \item Uživatel se přihlásí do systému a vyplní formulář s novou kartou
    \item Nová karta se ověří s bankovním účtem
    \item Správce účtu kartu s jejími údaji uloží do databáze
    \item Z údajů na kartě vytvoří hash a odešle ho ve zprávě, že systém zaregistroval novou kartu.
    \item Generátor účtenek tuto informaci zachytí a uloží si daný hash do vlastní databáze.
    \item V případě zjišťování pokladního systému, jestli dokáže BillSaver přijmout hash dané karty, generátor bude moct odpovědět na základě interní databáze zaheshovaných karet, které systém přijímá.
\end{enumerate}

\subsection{Verifikace dat}

\begin{enumerate}
    \item Když správce účtenek ohlásí příchod nové účtenky pro daného spotřebitele, správce zboží tuto zprávu zachytí.
    \item Správce zboží ze zprávy vyextrahuje EAN kódy zboží.
    \item Tyto EAN kódy porovná se svojí databází produktu.
    \item Správce ověří, že zboží existuje a je kompletně vyplněné.
    \item V případě, že je zboží vyplněno, systém nic nedělá. Pokud však  zaznamená chybějící informace o zboží ze zprávy, vyextrahuje, od kterého prodejce účtenka přišla, a pošle zprávu obchodníkovi o doplnění informací o zboží.
    \item Zprávu zachytne notifikační služba, která mu na základě obchodních preferencí tuto zprávu pošle do předdefinovaných komunikačních kanálů.
    \item Stejně tak tuto zprávu zachytí i obchodní informační služba, která přiřadí dotaz o doplnění těchto informací k obchodnímu profilu.
\end{enumerate}

\subsection{Přidání a úprava zboží}

\begin{enumerate}
    \item Pokud bude chtít obchodník přidat nové zboží, nebo stávající zboží upravit, přihlásí se do obchodního informačního systému. 
    \item Tam pomocí automatického načítacího systému nebo vyplnění dotazníku uvede informace o novém či upraveném zboží. 
    \item Informační systém tuto informaci odešle.
    \item Správce zboží tuto zprávu zachytí.
    \item Data ve zprávě se verifikují a doplní se do databáze.
\end{enumerate}