Architektura warstwowa

Architektura warstwowa – sposób na organizację kodu

Jednym ze sposobów radzenia sobie z rozrastającym się kodem aplikacją jest architektura warstwowa. Model warstwowy jest jednym z najbardziej rozpowszechnionych modeli architektury aplikacji. Ale czy jest najlepszy i czy nadaje się do każdej aplikacji dowiesz się z poniższego artykułu.

Co to jest architektura warstwowa?

Architekturę warstwową aplikacji możemy sprowadzić do prostego podziału aplikacji na techniczne warstwy. Jego najpopularniejszą odmianą jest chyba model trój warstwowy. Ale ilość warstw nie jest tu aż tak istotna. Zdarzało mi się pracować z aplikacjami, które miały 3-4 warstwy, ale były też takie, w których było aż 7 warstw. Ważny jest tutaj sam podział i to jak ten podział przebiega.

W aplikacjach możemy wydzielić np. takie warstwy:

  • prezentacji
  • logiki biznesowej
  • danych (warstwa zapisu danych)

Oczywiście nazwy tych warstw są bardzo dowolne. Nie ma żadnego standardu określającego jak te warstwy powinny się nazywać. I właściwie każdy nazywa je po swojemu.

Kolejną istotną rzeczą jest to, że warstwy kolejno zależą od siebie, ale jest to zależność tylko w jednym kierunku:

Architektura warstwowa

Po co korzystać z architektury warstwowej

Głównym powodem stosowania tej architektury jest poprawa organizacji kodu. Rozdzielamy kod na warstwy, które mają przypisane odpowiednie odpowiedzialności.

I np. kod związany z zapisem danych do bazy nie powinien znajdować się w warstwie prezentacji. Kod zawierający logikę biznesową aplikacji nie powinien znajdować się w warstwie danych itd.

Każda warstwa ma przypisaną swoją odpowiedzialność i kod zawarty w tych warstwach powinien spełniać warunki przynależności do danej warstwy.

 

Architektura warstwowa w aplikacji

W aplikacji wyznacznikiem tych warstw mogą być pakiety. Dla typowej aplikacji springowej mamy warstwy kontrolerów, serwisów i repozytoriów. W każdym z tych pakietów będziemy mieli odpowiednie klasy:

 

Warstwy - architektura warstwowa

 

  • controller – warstwa aplikacji – w warstwie tej wywołujemy odpowiednie serwisy i przetwarzamy parametry wejściowe
  • service – warstwa logiki biznesowej – tutaj zawarta jest cała logika aplikacji
  • repository – warstwa dostępu do danych – w tej warstwie przetwarzamy dane pod kątem zapisu ich do bazy danych

Tak zorganizowany kod działa w następujący sposób: kontroler wywołuje metody z serwisu, serwis wywołuje metody z repozytorium. A takie pakietowanie możemy nazwać pakietowaniem po warstwach (package by layer).

Architektura warstwowa jest bardzo prosta i łatwa w zastosowaniu. Ale co zrobić gdy klas jest coraz więcej i taki prosty podział zaczyna być uciążliwy. Kilkadziesiąt klas w jednym pakiecie przestaje być czytelne i proste w obsłudze.

W takim wypadku możemy podzielić warstwy dodatkowo na pakiety funkcjonalne. Ułatwi to trochę organizację dużej ilości klas i poprawi czytelność.

 

Warstwy funkcjonalne - architektura warstwowa

 

W każdym pakiecie funkcjonalnym będziemy mieli klasy, które są związane z daną funkcjonalnością. Przydaje się to zwłaszcza w warstwie logiki biznesowej, gdzie klas jest zwykle najwięcej.

Jeśli mamy skomplikowaną logikę biznesową aplikacji, to często dzieje się tak, że jest potrzeba rozdzielenia kodu na wiele serwisów. Wtedy jeden serwis wywołuje inny serwis (lub kilka serwisów) i czasem hierarchia klas jest bardzo rozbudowana. Z kolei każdy serwis może wywoływać po kilka repozytoriów. Przy takiej skomplikowanej hierarchii klas najlepiej jest otestować wszystko testami jednostkowymi, wtedy mamy pewność, że wszystko działa tak, jak należy.

A jeśli chcemy mieć jeszcze bardziej czytelną strukturę pakietów, możemy zastosować pakietowanie, które jest wariacją na temat powyższego pakietowania i jest to pakietowanie funkcjonalne najpierw po funkcjonalnościach, a dopiero później po warstwach (package by feature).

pakietowanie po funkcjonalnościach

Taką architekturę można zastosować do prawie każdej aplikacji, czy to będzie aplikacja konsolowa, webowa, czy okienkowa. Chociaż nie do każdej aplikacji ta architektura będzie najlepsza…

 

Zalety architektury warstwowej

  • prostota – jest to na tyle prosta architektura, że każdy programista jest w stanie w krótkim czasie zrozumieć o co w niej chodzi
  • powszechnie wykorzystywana – jest stosowana w bardzo wielu aplikacjach, więc wielu programistów zna ją bardzo dobrze
  • separacja odpowiedzialności – pozwala rozdzielić klasy o różnym przeznaczeniu. Każda warstwa odpowiada za odpowiednie elementy aplikacji. Różne komponenty aplikacji nie mieszają się ze sobą. Co jest chyba największą zaletą tej architektury.

 

Wady architektury warstwowej

  • trudno skalowalna – gdy ilość kodu urośnie do bardzo dużych rozmiarów, coraz trudniej będzie zarządzać zmianami w kodzie i zachować porządek w projekcie
  • zaciemnia obraz aplikacji – patrząc tylko na same warstwy, tak naprawdę trudno jest odpowiedzieć na pytanie co aplikacja robi, co i jak jest powiązane ze sobą, co z czego wynika
  • może łamać zasadę Dependency Inversion Principal jeśli zależności pomiędzy warstwami będą przebiegać tylko w jedną stronę. Komponenty wyższego poziomu zależą wtedy bezpośrednio od komponentów niższego poziomu.
  • warstwy są ze sobą ściśle powiązane – wynika to bezpośrednio z samej architektury i może stanowić problem gdy aplikacja znacząco się rozrośnie

 

Jeśli potrzebujesz bardziej kompleksowego wyjaśnienia na temat Architektury warstwowej, to przygotowałem warsztat na temat tej architektury, także z zakodowaniem przykładu i z wyjaśnieniem rozmieszczenie elementów aplikacji w tej architekturze. Warsztat Architektura Warstwowa ze szczegółowym opisem znajdziesz tutaj.

 

Podsumowanie

Architektura warstwowa to jedna z najprostszych architektur do zastosowania w aplikacji. Pomaga zorganizować kod w logiczne warstwy, dzięki czemu komponenty o różnych odpowiedzialnościach nie mieszają się ze sobą. Może być stosowana w prawie każdej sytuacji, zwłaszcza do małych aplikacji o niewielkiej bazie kodowej. Dopiero przy większej ilości kodu może sprawić problem.

 

Mateusz Dąbrowski

Cześć jestem Mateusz, zajmuję się programowaniem już ponad 12 lat z czego ponad 8 programuję w Javie. Zapraszam Cię do lektury mojego bloga. Możesz przeczytać więcej o mnie >>TUTAJ<<

10 thoughts to “Architektura warstwowa – sposób na organizację kodu”

  1. Jestem bardzo na tak, jeśli chodzi o wszelkie informacje związane z organizacją kodu. Praktycznie jak chcę zrobić coś więcej niż program na jeden, dwa pliki to szybko zaczyna się robić śmietnik i jako początkujący nie za bardzo wiem jak sobie z tym poradzić.

  2. Czekam na artykuł o podziale funkcjonalnym 🙂

    1. O podziale funkcjonalnym masz wzmiankę w tekście i imho jest to dosyć proste.
      Ciekawsza byłaby by analiza wzorca portów i adapterów.

    2. Jakaś to struktura jest. Jednak w pojeciu DDD na pewno nie warstwowa. Z tego co orientuje się teraz w branży dobre praktyki to umieszczenie wszelkiej komunikacji z aplikacją np kontrolery w warstwie boundry, serwisy oraz encje w warstwie domenowej, persystencja i implementację zewnętrznych interfejsów w warstwie infrastruktury. Dąży się do odseparowania odpowiedzialności warstw, co nie do końca jest zapewnione w przykładzie.

      1. Jest to jak najbardziej architektura warstwowa. Wpychanie wszędzie na siłę DDD nie jest dobrym sposobem organizacji kodu. Napisałem tutaj o klasycznej architekturze warstwowej (i przykład to odzwierciedla), która jak najbardziej zapewnia separację odpowiedzialności, a właściwie to nie architektura zapewnia tę separację tylko developerzy 😉 Architektura może im w tym tylko pomagać.

        „Z tego co orientuje się teraz w branży dobre praktyki to umieszczenie wszelkiej komunikacji z aplikacją np kontrolery w warstwie boundry” – dobrą praktyką jest rozpatrywanie każdego przypadku osobno. Inne reguły zastosujesz do aplikacji CRUD, którą będziesz developował przez kilka dni a później świat o niej zapomni, a inne do aplikacji, która będzie rozwijana przez kolejne 5 lat przez zespół 30 developerów.

        Artykuł jest o architekturze warstwowej a nie o DDD (chociaż tam też są warstwy 😉 )

  3. Java 14 w ogóle jest na produkcji? Czy Java 14 i Java 17 to takie same wersje LTS czy tylko Java 8 i 17 będą pełnymi wersjami LTS?

    1. Raczej nie wiele firm używa produkcyjnie Javy 14. Obecnie LTSy to 8 i 11. Kolejna wersja LTS wyjdzie dopiero we wrześniu 2021 i będzie to Java 17. Polecam korzystanie z 11-tki, a jak masz projekty niekomercyjne to także z 14-tki.

      1. Dopiero uczę się Javy 11 i korzystam z OpenJDK. Ten film na youtube dał mi trochę do myślenia, gość odradza 5 języków programowania których nie warto się uczyć w 2020 roku. Zapewne nie dotyczy to starszych programistów, którzy już programują w danym języku od kilku lat.
        [link usunięty:to jest opinia tego człowieka, nie chcę jej rozpowszechniać u siebie na blogu]

  4. Z tego spokojnie mógłbyś wyjść jak zbudować aplikacje z mavenem pod spodem 😉 i podziałem na moduły / pom.

Komentarze są zamknięte.