W tym poście dowiesz się, czym jest architektura wielowarstwowa aplikacji i po co się ten wzorzec projektowy używa. Wyjaśnię, za co warstwy są odpowiedzialne oraz kiedy się to stosuje.
Cebula ma warstwy
Zawsze gdy słyszę lub czytam o warstwach, przed oczami ukazuje mi się bajka o zielonym stworze z genialnym dubbingiem Jerzego Stuhra. Kiedy to ogr mówi wiekopomne: "Cebula ma warstwy. Ogry mają warstwy". Aplikacje też mają warstwy.
Myślę, że warto wspomnieć, że termin architektura w IT, jest używany w 2 kontekstach:
jak zbudowana jest konkretna aplikacja (architektura aplikacji),
jak zbudowana jest architektura n aplikacji i ich powiązania — często można usłyszeć termin architektura systemowa lub ekosystem aplikacyjny.
Co to?
Gdy rozwijamy aplikację, wzrasta jej kod źródłowy. To determinuje, że poziom skomplikowania zaimplementowanych rozwiązań w kodzie również wzrasta. By sobie z tym radzić, najczęstszym wdrażanym rozwiązaniem jest podzielenie aplikacji na warstwy.
Pojedyncza warstwa to logiczny mechanizm strukturyzujący elementy tworzące aplikację. Wyróżniamy 2 typy warstw: logiczne i fizyczne. Każda z tych warstw może posiadać w sobie komponenty.
Komponentem nazywamy re używalną część kodu, który można łączyć z innymi komponentami w celu utworzenia aplikacji. Takim najprostszym przykładem komponentu będzie przycisk w aplikacji lub interfejs do bazy danych.
Sam wzorzec nie wskazuje konkretnej liczby warstw, które powinna aplikacja mieć. Wzorzec ten w języku angielskim ma określenie n-layered/n-tier, gdzie pod zmienną n kryje się liczba warstw. Liczba warstw wykorzystanych w aplikacji często zależy to od przyjętych standardów firmowych oraz dojrzałości programistów pracujących nad produktem. Natomiast, najczęściej spotykaną w praktyce jest aplikacja trójwarstwowa.
Architektura wielowarstwowa — odpowiedzialność warstw
Aby dobrze zobrazować, na czym polega architektura wielowarstwowa i w jakim celu wprowadza się wprowadzenie odpowiedzialności, pozwolę sobie omówić jako przykład aplikację trójwarstwową. Jak nazwa sama wskazuje w takiej aplikacji mamy 3 warstwy. Każda ma swoją odpowiedzialność:
interfejs użytkownika (User Interface (UI)) potocznie nazywany frontendem — to element aplikacji, który jest odpowiedzialny za komunikację z użytkownikami. Upraszczając, to jest to wszystko, co widzisz gołym okiem w Internecie, na komputerze, telefonie. Tę warstwę interesuje tylko, co i w jakim formacie ma wyświetlić użytkownikowi. Nie dba ona np. o jakość wyświetlanych danych. Dobrym przykładem jest podpowiedź, czy wpisany numer telefonu w formularzu jest właściwy.
logikę biznesową często skrótowo nazywana backendem - tutaj zakodowane jest całe zachowanie aplikacji. To ta warstwa "mówi" co ma Ci się wyświetlić na UI na podstawie zebranych danych: zachowanie użytkownika, zapisach w bazach danych. Nie interesuje jej np. jak sformatować dane do wyświetlenia ich użytkownikowi. Przykładowo — kiedy w sklepie internetowym wykorzystujesz kod rabatowy, logika biznesowa oblicza, jakie powinny być kwoty na poszczególnych artykułach. A UI to tylko wyświetla.
warstwę danych — ta warstwa odpowiada za komunikację aplikacji z innymi systemami tj. bazami danych oraz wykorzystanie sieci w tym celu. To stąd wiesz, jaki masz numer zamówienia albo jego status.
Po co?
Wprowadzenie architektury wielowarstwowej do aplikacji pozwala na:
wytyczenie odpowiedzialności za kawałek aplikacji, czyli, czym się dana warstwa będzie zajmować,
lepsze zarządzanie zależnościami,
determinuje kierunek wykorzystania warstw między sobą (z zasady "wyższa" warstwa może wykorzystywać usługi z warstwy "niżej"),
rozdzielenie aplikacji na kilka maszyn i wykorzystanie różnych typów infrastruktury,
łatwiejsze zarządzanie aplikacją w kontekście architektury systemowej,
zmiany w jednej warstwie, nie wpływają na pozostałe, ograniczają się tylko do komponentów w tej warstwie,
łatwiejszy refaktoring w ramach warstw.
Epilog
Oczywiście trzeba zachować zdrowy rozsądek i nie tworzyć "miliona" warstw w aplikacji, bo spowoduje to problemy z latencją (lag). Jest to antywzorzec i ma swoją nazwę "architecture sinkhole anti-pattern" ;).
Pozwolę sobie nadmienić, że ten wzorzec wykorzystywany jest w aplikacjach monolitycznych. Przy aplikacjach rozproszonych wykorzystuje się inne wzorce, które poruszę w innych postach.
Jeśli zaciekawił Cię ten temat i masz głód wiedzy, podrzucam przydatne hasła do wyszukania u wujka Google: n-layered architecture, n-tier architecture.