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:

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:

• 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ść.

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).

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.