Architektura warstwowa. Z艂o czy dobro? 馃

Architektura warstwowa – z艂o konieczne a mo偶e optymalne rozwi膮zanie? Pewne jest jedno – jest to najpopularniejszy styl architektoniczny w艣r贸d developer贸w. Cz臋sto (niestety) jedyny jaki znamy.


Cze艣膰聽馃檪

Ka偶dy z nas u偶ywa艂 architektury warstwowej, czy to przechodz膮膰 przez tutorial w sieci czy implementuj膮c aplikacje komercyjne lub niekomercyjne. Jest ona na tyle popularna, 偶e a偶 bardzo cz臋sto u偶yta tam gdzie wcale nie sprawdza si臋 najlepiej. Niemniej jednak, nie chc臋 偶eby ten artyku艂 szed艂 w stron臋, 偶e architektura warstwowa jest z艂em. Absolutnie nie! B臋d膮c 艣wiadomym programist膮 powinni艣my umie膰 dobra膰 odpowiedni膮 architektur臋 do problemu jaki jest przed nami (i naszym zespo艂em!).

W dzisiejszym artykule:


Czym jest architektura warstwowa?

Na pocz膮tku musimy zacz膮膰 w og贸le od wyja艣nienia czym jest architektura warstwowa. Je偶eli jete艣 programist膮 (a zak艂adam, 偶e jeste艣) to na 100% ju偶 si臋 z ni膮 spotka艂e艣. W teorii zak艂ada ona podzia艂 strukturalny projektu na kilka warstw. W wielu przypadkach b臋d膮 to g艂贸wnie 3 warstwy: prezentacji, logiki oraz persystencji. Aczkolwiek nie ma problemu 偶eby warstw by艂o 5 lub 2.

呕eby艣 m贸g艂 to sobie lepiej zobrazowa膰 to te 3 warstwy przyr贸wnam do typowej aplikacji pisanej w springu:

    • warstwa prezentacji = kontrolery,
    • warstwa logiki = serwisy,
    • warstwa persystencji = repozytoria.

Architektura warstwowa ma dwa fundamentalne za艂o偶enia:

    1. ka偶da warstwa jest odseparowana od siebie – wykonuje tylko t膮 prac臋 do kt贸rej zosta艂a stworzona.
    2. komunikacja jest kierowana od g贸ry do do艂u (warstwa prezentacji wykorzystuj臋 logik臋 a ta persystencj臋)

Obrazek pochodzi z kursu DNA

Pomimo, 偶e zasada numer dwa, kt贸ra m贸wi i偶 komunikacja jest kierowana od g贸ry do do艂u mo偶e sugerowa膰 wprowadzenie zale偶no艣ci pomi臋dzy warstwami to takie my艣lenie nie jest poprawne. Warstwy s膮 od siebie niezale偶ne. S膮 one tylko powi膮zane (wywo艂anie warstwy ni偶szej przez warstw臋 wy偶sz膮) ale nie nale偶y myli膰 tego z zale偶no艣ci膮. W praktyce oznacza to, 偶e implementacje warstw mog膮 by膰 艂atwo wymienne. Je偶eli chcemy zamieni膰 persystencj臋 z Hiberneta na MyBatis to nie powinno to wp艂ywa膰 jakkolwiek na inne warstwy.

Mo偶emy sobie wyobrazi膰 sytuacje kiedy piszemy bardzo prostego CRUD’a. Nie posiada on logiki biznesowej (lub posiada jej bardzo ma艂o). Czy powinni艣my w takim razie tworzy膰 warstw臋 logiki? S膮 dwie szko艂y. Jedna, bardziej restrykcyjna m贸wi膮ca, 偶e obligatoryjnie tworzymy wszystkie warstwy wymagane w projekcie a przep艂yw w naszej aplikacji jest zawsze taki sam. Przy takim podej艣ciu m贸wi si臋, 偶e warstwy s膮 zamkni臋te. Natomiast druga szko艂a pozwala na rozlu藕nienie, warstwy mog膮 by膰 otwarte. Kt贸re podej艣cie jest lepsze? Oba s膮 prawid艂owe. W architekturze jest du偶o abstrakcji i stety, niestety wyraz to zale偶y mo偶e by膰 u偶ywany bardzo cz臋sto.

Obrazek pochodzi z kursu DNA

Dlaczego to zale偶y? Zobacz, mogliby艣my zezwoli膰 na wywo艂anie warstwy persystencji bezpo艣rednio przez warstw臋 prezentacji. Chyba by艣my tym nie zgrzeszyli? Natomiast pozwalaj膮c sobie na takie manewry rozlu藕niamy granice naszej aplikacji. Nie tylko my pozwalamy na rozlu藕nienie ale jest jeszcze ca艂y zesp贸艂. Kiedy komunikacja w zespole nie jest na najlepszym poziomie lub nad modu艂ami pracuje kilka zespo艂贸w (jest to uci膮偶liwe zw艂aszcza przy du偶ych projektach) nasza architektura staje si臋 krucha. Nie kontrolujemy, kt贸re warstwy mog膮 by膰 otwarte a kt贸re nie. Kod staje si臋 ci臋偶szy w testowaniu i utrzymywaniu a zale偶no艣ci mi臋dzy warstwami narastaj膮.


Rzeczywisto艣膰 architektury

Problem z architektur膮 warstwow膮 jest taki, 偶e w rzeczywisto艣ci wygl膮da ona nieco inaczej. Mamy modu艂y naszej aplikacji i przep艂yw od g贸ry do do艂u. Dop贸ki aplikacja nie jest du偶a, udaje nam si臋 utrzyma膰 prawid艂owy przep艂yw. Problemem jest moment w kt贸rym aplikacja masowo przyrasta – zwi臋ksza si臋 ilo艣膰 zespo艂贸w nad ni膮 pracuj膮cych, powstaj膮 nowe, szybkie featuer’y. Biznes chce widzie膰 efekty jak najszybciej, tworzy presj臋 na developerach a to zazwyczaj prowadzi do tego, 偶e nie my艣limy o designie aplikacji jako ca艂o艣ci. Skupiamy si臋 wy艂膮cznie na tym co chemy dostarczy膰 w tym momencie – jak najszybciej. Ko艅cowo doprowadza to do architektury warstwowej, kt贸ra ju偶 nie wygl膮da tak pi臋knie jak by艂a przedstawiana w tutorialach.

Obrazek pochodzi z kursu DNA

Istnieje rozwi膮zanie tego problemu. Wymaga ono jednak zastanowienia si臋 do czego b臋dzie nam s艂u偶y膰 dany feature. Czy nie powinien by膰 on osadzony w osobnym module? Dodatkowy podzia艂 aplikacji na modu艂y – gdzie ka偶dy z modu艂贸w ma swoj膮 implementacj臋 architektury jest z艂otym 艣rodkiem. Wiem, 偶e znajd膮 si臋 przeciwnicy tego rozwi膮zania m贸wi膮c, 偶e robi nam si臋 wtedy misz-masz r贸偶nych styli architektonicznych. Macie racj臋 :). Trzeba to dopasowa膰 odpowiednio do umiej臋tno艣ci zespo艂u. Co na przyk艂ad stoi na przeszkodzie 偶eby jeden modu艂 wykorzystywa艂 architektur臋 tr贸jwarstwow膮 a drugi dwuwarstwow膮? Moim zdaniem nic. Nale偶y tylko umie膰 odpowiednio zdiagnozowa膰 problem jaki rozwi膮zujemy. Sprawdzi膰, czy robimy CRUD’a czy co艣 co wymaga bardziej z艂o偶onej logiki. No i jeszcze bardzo wa偶ne – trzyma膰 si臋 za艂o偶e艅 jakie poczynili艣my.

(Ot takie moje dumanie..)


Wady i zalety architektury warstwowej

Zalety:

  • Powszchechna. Wi臋kszo艣膰 ludzi j膮 zna i nie b臋dzie mia艂o problemu 偶eby odnale藕膰 si臋 w projekcie.
  • Zmniejsza z艂o偶ono艣膰 – warstwy niskopoziomowe mo偶emy zast膮pi膰 warstwami wy偶szymi. Co艣 a’la fasada.
  • Separuje odpowiedzialno艣膰 – pozwala na wymian臋 implementacji poszczeg贸lnej warstwy bez wp艂ywu na inn膮

Wady:

  • Zmiany wymagane w wielu warstwach. Zmieniaj膮c warstw臋 widoku prawdopodobnie b臋dziemy musieli r贸wnie偶 dotkn膮膰 warstwy logiki i persystencji.
  • Ukryty cel – patrz膮c na struktur臋 projektu nie jeste艣my w stanie powiedzie膰 jaki problem rozwi膮zuje. Dopiero spojrzenie w klasy znajduj膮ce si臋 w pakietach co艣 nam zaczyna podpowiada膰.

W wielu wpisach na mediach jako zalet臋 tej architektury wymienia si臋 r贸wnie偶 testowalno艣膰. Nie zgadzam si臋 z tym stwierdzeniem w 100% ale te偶 nie neguj臋. Owszem, mo偶emy testowa膰 wy艂膮cznie jedn膮 warstw臋, tylko problem jaki widz臋 jest taki, 偶e ko艅czy si臋 to na mockowaniu 99 obiekt贸w i testowaniu jednej malutkiej funkcjonalno艣ci. To jest z艂e ale nie jest tragiczne. Tragedia przychodzi kiedy w mockowanych API powstaj膮 zmiany i nasz test dalej przechodzi pomimo, 偶e ju偶 nie powinien. W taki spos贸b powstaj膮 testy, kt贸re zadawalaj膮 biznes pokryciem kodu ale w rzeczywisto艣ci s膮 do wyrzucenia… to jest temat na inny wpis.


Podsumowanie

Architektura warstwowa to dobre rozwi膮zanie w wielu przypadkach. Pozwala na szybki rozw贸j aplikacji w pocz膮tkowych fazach a dodatkowo dzi臋ki jej zastosowaniu wiemy, 偶e ka偶dy nowy cz艂onek zespo艂u wdro偶y si臋 w miar臋 szybko. Je偶eli tworzymy aplikacj臋, kt贸ra nie jest du偶a to moim zdaniem architektura warstwowa mo偶e spe艂ni膰 swoje zadanie doskonale.

Czasami mamy inne potrzebny a realia s膮 niestety takie, 偶e wi臋kszo艣膰 programist贸w nie zna styl贸w architektury. To powoduje, 偶e bez edukacji zespo艂u nie jeste艣my w stanie wdro偶y膰 czego艣 bardziej odpowiedniego. Dlatego wa偶ne jest aby szerzy膰 wiedz臋 i uczy膰 si臋 nowych rzeczy – r贸wnie偶 o architekturze 馃檪

殴r贸d艂a:


Za tydzie艅

Kolejny wzorzec architektoniczny: Event-Driven Architecture. My艣l臋, 偶e przelecimy przez wszystkie wzorce z ksi膮偶ki Mark’a Richards’a. Jest to edukuj膮ce i ciekawe.

5 2 votes
Article Rating
Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments