top of page
Szukaj
  • Zdjęcie autoraKate Prokopiuk

Architektura wielowarstwowa aplikacji

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.

Budowa aplikacji trójwarstwowej
Budowa aplikacji trójwarstwowej

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.


247 wyświetleń0 komentarzy

Ostatnie posty

Zobacz wszystkie

Comments


bottom of page