Dobre praktyki projektowania architektury oprogramowania, które warto znać

Tworząc produkt, warto pomyśleć o tym, jak będzie utrzymywany w przyszłości. Trzeba przemyśleć specyfikę wprowadzania zmian i edytowania funkcji. Ważne jest też zrozumienie, jak zewnętrzne elementy interfejsu współdziałają z procesami wewnętrznymi i według jakich zasad architektury użytkownicy będą korzystać z programu. 

Pomagają w tym opisane niżej dobre praktyki projektowania architektury oprogramowania. Najpierw jednak ustalmy, czym jest architektura oprogramowania, jak działa i po co się ją projektuje.

Czym jest architektura oprogramowania?

Architektura oprogramowania to zaprojektowana struktura programu, obejmująca zdefiniowanie interakcji komponentów interfejsu z wewnętrznymi procesami programu. Mówiąc prosto, to podejście określające, które funkcje za co odpowiadają i jak się ze sobą komunikują.

Nie ma jednego precyzyjnego rozumienia ani jasnej definicji tego procesu. Głównym zadaniem jest stworzenie logicznej struktury programu i uproszczenie współpracy między programistami. W ten sposób osiągniemy wysoki poziom skalowalności architektury. To z kolei pozwala w przyszłości wprowadzać zmiany w programie, pracując nad konkretnymi aspektami, zamiast przeprojektowywać całe oprogramowanie. 

Dobre praktyki projektowania architektury oprogramowania sprawiają, że aplikacja wykona zadania i spełni cel określony na początkowych etapach prac.

Po co stosować dobre praktyki projektowania architektury oprogramowania

Architektura aplikacji spełnia szereg ważnych zadań:

• Określa strukturę programu i pozwala zrozumieć, jak jest zbudowany oraz na których poziomach wykonywane są poszczególne zadania i funkcje;
• Określa zachowanie i interakcję elementów, dzięki czemu wiadomo, co się dzieje po wykonaniu danego działania;
• Określa elementy istotne i drugorzędne, co pozwala oszacować koszt wytworzenia. Pomaga też zrozumieć, które elementy trzeba wdrożyć, a z których można zrezygnować ze względów oszczędnościowych;
• Pomaga zrozumieć, jak skalowalna jest aplikacja, jak trudno będzie wdrożyć nowe funkcje i jakiego stosu technologicznego użyć;
• Pozwala spełnić potrzeby klienta i dopasować program do wzajemnie wykluczających się wymagań, na przykład wysokiej funkcjonalności i wyznaczonych terminów - staje się wtedy jasne, jak to wdrożyć;
• Pozwala zrozumieć logiczne zależności w programie;
• Umożliwia poprawne prowadzenie dokumentacji i jasne opisanie funkcji, co znacznie ułatwia dalsze utrzymanie programu, wprowadzanie zmian i pracę z istniejącymi funkcjami.

To główne zadania, które spełnia architektura oprogramowania. Stosując dobre praktyki jej projektowania, znacznie upraszczasz wytwarzanie i dokładnie wiesz, jaki będzie efekt i jak zadziałają wszystkie funkcje. 

Architektura projektu programistycznego pozwala tworzyć wysokiej jakości oprogramowanie i dodatkowo obniżyć koszty jego utrzymania oraz serwisu.

Architekci oprogramowania

Kim są

Architekt oprogramowania (architekt systemów, architekt IT) to specjalista, który buduje złożone systemy IT rozwiązujące problemy biznesowe. Architekt systemów dobrze zna procesy biznesowe i widzi, jak problem biznesowy można rozwiązać przy użyciu różnych technologii informatycznych. Odgrywa ważną rolę w projektowaniu architektury systemu i definiowaniu produktu programistycznego.

Czym zajmuje się architekt oprogramowania?

• Bada obszar tematyczny pod wdrożenie i/lub rozwój użytkowych systemów informatycznych (na przykład analizuje dobre praktyki w tworzeniu aplikacji iOS)
• Analizuje dobre praktyki projektowania architektury oprogramowania, by wybrać tę najlepiej dopasowaną
• Bierze udział w wywiadach z klientami, ekspertami biznesowymi i użytkownikami systemów informatycznych, by poznać obecne zasady organizacji przebiegu procesów
• Przegląda i porządkuje dokumentację projektową
• Przygotowuje dokumenty techniczne opisujące encje, relacje i procesy z danego obszaru przy użyciu specjalnych notacji
• Bierze udział w stawianiu zadań i tworzeniu specyfikacji technicznej
• Zbiera, analizuje i dokumentuje wymagania funkcjonalne wobec oprogramowania
• Nadzoruje prace programistyczne
• Bierze udział w przygotowaniu schematów testów funkcjonalnych, by wychwycić odstępstwa od sformułowanych wymagań biznesowych i funkcjonalnych
• Bierze udział w testowaniu prototypu tworzonego systemu
• Bierze udział w szkoleniu użytkowników systemu
• Analizuje ryzyka i przyczyny błędów powstających podczas budowy systemu

Wytyczne i zasady organizowania systemów informatycznych

Architektura warstwowa

Ta dobra praktyka projektowania architektury oprogramowania działa na zasadzie rozdzielenia odpowiedzialności. Oprogramowanie dzieli się na warstwy leżące jedna na drugiej, a każda z nich pełni określone zadanie.

Architektura dzieli oprogramowanie na następujące warstwy:

1. Warstwa prezentacji zawiera interfejs użytkownika i odpowiada za dobre doświadczenie użytkownika.
2. Warstwa logiki biznesowej, jak sama nazwa wskazuje, zawiera logikę biznesową aplikacji. Oddziela UI/UX od obliczeń związanych z biznesem. Dzięki temu łatwo zmienisz logikę wraz ze zmieniającymi się wymaganiami biznesowymi, nie ruszając w żaden sposób pozostałych warstw.
3. Warstwa dostępu do danych odpowiada za komunikację z trwałymi magazynami, takimi jak bazy danych, oraz za inne przetwarzanie informacji niezwiązane z biznesem.

Dane i sterowanie przepływają w tym projekcie przez każdą warstwę i są przekazywane z jednej do następnej. Ten system podnosi też poziom abstrakcji, a do pewnego stopnia nawet stabilność oprogramowania.

Zalety

• Łatwiejsze wdrożenie w porównaniu z innymi podejściami.
• Daje abstrakcję dzięki rozdzieleniu odpowiedzialności między poziomami.
• Izolacja chroni część warstw przed zmianami w innych.
• Zwiększa zarządzalność oprogramowania dzięki luźnym powiązaniom.

Wady

• Nie oferuje dużej skalowalności.
• Oprogramowanie stworzone w tym podejściu będzie miało strukturę monolityczną, co utrudnia modyfikacje.
• Dane muszą przejść przez każdą warstwę, nawet jeśli nie trzeba ich przekazywać z konkretnych warstw.

Znany przykład z życia: Gmail.

Architektura sterowana zdarzeniami

Firmy takie jak Uber, Twitter czy LinkedIn żyją aktualizacjami w czasie rzeczywistym: powiadomienia o przejazdach Ubera, tweety znajomych i przydatne wskazówki ekspertów branżowych, które można odebrać i udostępnić w kilka sekund. 

Gdy tylko informacja trafia do sieci, natychmiast staje się dostępna dla wszystkich dookoła. Użytkownicy zawsze pokochają tę prostą i szybką dostępność informacji - stale wypatrują podobnych ułatwień w swoim życiu.

Żeby sprostać stale rosnącym oczekiwaniom konsumentów, wiele firm musi porzucić tradycyjne struktury żądanie-odpowiedź na rzecz architektur sterowanych zdarzeniami.

W przeciwieństwie do systemów żądanie-odpowiedź w architekturze sterowanej zdarzeniami zgłaszający wysyła zdarzenie (zwykle wiadomość z [nagłówkiem] i [ładunkiem]) do warstwy dystrybucji. Wiadomość może następnie odebrać usługa nasłuchująca konkretnego tematu. Usługa może potem w jakiś sposób wykorzystać ładunek wiadomości albo przekazać ją dalej do innej usługi.

Zalety

• Wynik w czasie rzeczywistym
• Łatwa skalowalność
• Odporność na awarie i wysoka dostępność

Wady

• Większa złożoność po stronie dostawcy API
• Niejednoznaczność w analityce API
• Ograniczony nadzór, standaryzacja i wsparcie dla programistów

Znane przykłady z życia: Netflix, Unilever, SAP, Amazon, LinkedIn i Federalna Administracja Lotnictwa.

Architektura mikrojądra

Architektura mikrojądra to alternatywa dla klasycznego sposobu budowania systemu operacyjnego. Klasyczna architektura oznacza w tym przypadku taką organizację strukturalną systemu operacyjnego, w której wszystkie główne funkcje systemu tworzące wielowarstwowe jądro wykonywane są w trybie uprzywilejowanym.

Istota tej dobrej praktyki projektowania architektury oprogramowania jest następująca. W trybie uprzywilejowanym działa tylko bardzo mała część systemu operacyjnego, zwana mikrojądrem. 

Mikrojądro jest chronione przed resztą systemu i aplikacjami. Zwykle obejmuje moduły zależne od maszyny, a także moduły realizujące podstawowe (ale nie wszystkie) funkcje jądra: zarządzanie procesami, obsługę przerwań, zarządzanie pamięcią wirtualną, przekazywanie komunikatów oraz zarządzanie urządzeniami wejścia-wyjścia związane z ładowaniem lub odczytem rejestrów urządzeń. Wszystkie pozostałe, wyższego poziomu funkcje jądra są pakowane jako aplikacje trybu użytkownika.

Zalety

• W dużym stopniu spełnia większość wymagań stawianych nowoczesnym systemom operacyjnym
• Przenośność - cały kod zależny od maszyny jest odizolowany w mikrojądrze, więc przeniesienie systemu na nowy procesor wymaga mniej zmian, a wszystkie są logicznie zgrupowane
• Rozszerzalność 
• Niezawodność 
• Tworzenie dobrych warunków do wspierania aplikacji rozproszonych

Wady

Te zalety mają swoją cenę w postaci niższej wydajności i to główna wada architektury mikrojądra. Przy klasycznej organizacji systemu operacyjnego wykonanie wywołania systemowego wiąże się z dwoma przełączeniami trybu, a przy organizacji mikrojądrowej - z czterema.

Dlatego system operacyjny oparty na mikrojądrze, przy pozostałych warunkach równych, zawsze będzie mniej wydajny niż system z klasycznym jądrem. Właśnie z tego powodu podejście mikrojądrowe nie przyjęło się tak szeroko, jak przewidywano.

Znane przykłady z życia: Mac OS X, Windows NT, Eclipse IDE.

Architektura mikroserwisowa

W tym podejściu aplikację tworzy się jako zestaw małych usług, z których każda działa we własnym procesie i komunikuje się lekkimi mechanizmami - zwykle API dla zasobu HTTP.

Usługi te opierają się na możliwościach biznesowych i mogą być wdrażane niezależnie, w pełni zautomatyzowanym mechanizmem.

Scentralizowane zarządzanie między usługami jest minimalne. Można je pisać w różnych językach i korzystać z różnych technologii przechowywania danych.

Architektura działa na zasadzie komponentyzacji przez usługi. Dzieli oprogramowanie na odizolowane komponenty (usługi), z których każdy ma jedną odpowiedzialność. Zmiany w jednej usłudze nie powinny wpływać na pozostałe.

Jedna z najpopularniejszych dobrych praktyk projektowania architektury oprogramowania to budowanie mikroserwisów w .NET.

Budowa mikroserwisów

Architektura składa się z odizolowanych, kompaktowych mikroserwisów, które mogą rozwijać się niezależnie od siebie. Obejmuje następujących 5 komponentów:

1. Usługi;
2. Szyna usług;
3. Konfiguracja zewnętrzna;
4. Brama API;
5. Kontenery.

Cechy mikroserwisów

Architektura mikroserwisowa powinna mieć następujące cechy:

• Komponentyzacja przez usługi.
• Organizacja wokół możliwości biznesowych.
• Skupienie na produktach, nie projektach.
• Inteligentne punkty końcowe i proste kanały.
• Zdecentralizowane zarządzanie.
• Zdecentralizowane zarządzanie danymi.
• Automatyzacja infrastruktury.
• Ochrona przed awariami.
• Projektowanie ewolucyjne.

Każdy mikroserwis warto rozwijać osobno, pod kontrolą innego zespołu. Ponieważ dane przesyła się standardowym protokołem i w standardowym formacie, struktura jednej usługi nie wpłynie na działanie usług powiązanych.

Zalety mikroserwisów

• Dają luźne powiązania dzięki wysokiemu stopniowi izolacji.
• Zwiększają modularność.
• Awaria jednej usługi nie wpłynie na cały system, bo usługi są odizolowane.
• Dają dużą elastyczność i skalowalność.
• Łatwość modyfikacji przyspiesza kolejne iteracje.
• Pozwalają wdrożyć lepszy system obsługi błędów.
• Rozwiązują problemy z przepływem danych, które ma architektura warstwowa.

Wady

• Większe ryzyko awarii przy komunikacji między usługami.
• Dużą liczbą usług trudno zarządzać.
• Wymagają zmierzenia się z opóźnieniami sieciowymi, równoważeniem obciążenia i innymi wyzwaniami typowymi dla architektury rozproszonej.
• Wymagają kompleksowych testów w środowisku rozproszonym.
• Wdrożenie potrwa znacznie dłużej.

Znane przykłady z życia: Uber, Netflix, Amazon, eBay i SoundCloud.

Serverless

Serverless computing (albo technologie serverless, jak się je czasem nazywa) to obiecujący model chmury obliczeniowej, który pojawił się w ostatnich latach na horyzoncie tworzenia aplikacji i architektury. To właśnie chęć wykorzystania ogromnego potencjału frameworków serverless sprawiła, że wielu dużych graczy rynkowych dało się porwać ogólnemu boomowi na usługi chmurowe. 

Giganci branży, tacy jak Google, Microsoft, IBM i Amazon, już proponują swoim klientom stosowanie dobrych praktyk projektowania architektury oprogramowania. Dzięki nim przeniesiesz lokalne procesy biznesowe i osiągniesz efektywność operacyjną na flagowych platformach serverless, takich jak AWS Lambda czy Azure Functions.

Mówiąc prosto, architektura serverless to rozwiązanie sterowane zdarzeniami i zapytaniami, które pozwala twórcom aplikacji tworzyć wydajne środowiska chmurowe ze wszystkimi zasobami obliczeniowymi potrzebnymi do płynnej pracy. Takie frameworki są bardzo wygodne, zwłaszcza przy napiętych terminach i zadaniach zasobożernych.

Co więcej, wybór usług serverless pozwala usprawnić procesy wytwarzania aplikacji, a przez to zwiększyć skuteczność innych praktyk optymalizacji procesów biznesowych, w tym DevOps i Agile.

Gdy porównamy architekturę serverless z mikroserwisami, ta pierwsza wygląda dla twórców aplikacji znacznie obiecująco, bo daje przestrzenie chmurowe na żądanie. Oznacza to, że funkcje serverless uruchamiają się dopiero po zaistnieniu określonego zdarzenia. Potem funkcje wykonują sekwencję operacji zależnie od poleceń otrzymanych od użytkowników. Platforma serverless stosuje wtedy zestaw wcześniej przygotowanych algorytmów i reguł, wykonuje obliczenia i dostarcza aktualne wyniki.

Zalety

• Oszczędności
• Większy potencjał innowacyjny
• Krótszy czas wprowadzenia na rynek
• Nie trzeba wybierać, zabezpieczać, aktualizować ani zarządzać systemami operacyjnymi
• Nie trzeba dobierać wielkości serwerów, monitorować ich ani skalować
• Nie ma ryzyka przepłacenia za nadmiarowe zasoby
• Nie ma ryzyka spadku wydajności z powodu niewystarczających zasobów

Wady

Z drugiej strony przekazanie kontroli nad częścią systemów podmiotowi trzeciemu rodzi też wady. Może to na przykład oznaczać pewną utratę kontroli i choćby niespodziewane aktualizacje API. Poza tym podzielenie jednej aplikacji na kilka części z wplecionymi w strukturę różnymi usługami zwiększa „liczbę punktów przegięcia”, co potrafi skomplikować testowanie.

Znane przykłady z życia: Netflix, Codepen, Zalora, Coca-Cola i Nordstrom.

Monolit

To podejście uchodzi za najlepsze przy budowaniu produktów w startupach. Wiele nowoczesnych firm wybiera architekturę monolityczną, bo ten zestaw dobrych praktyk projektowania architektury oprogramowania jest wygodny przy pracy z małymi grupami programistów. 

Przy jego stosowaniu wszystkie komponenty programu są ze sobą powiązane i wymienne - pomaga to rozwijać program jako autonomiczny i samowystarczalny. Architektura monolityczna uchodzi w tworzeniu aplikacji za tradycyjną i sprawdzoną, ale jednocześnie wielu programistów uważa to podejście za staroświeckie i już do niczego nieprzydatne.

Aby zrozumieć, czy lepszy będzie dla Ciebie monolit czy mikroserwisy - musisz rozważyć zalety i wady architektury monolitycznej.

Zalety

• Łatwe wytwarzanie i łatwe uruchomienie programu
• Problemy przekrojowe praktycznie nie występują
• Lepsza wydajność

Wady

• Duża ilość kodu
• Trudna modernizacja
• Ograniczona elastyczność
• Zależność między komponentami

Znane przykłady z życia: SalesForce i Hubspot

Role i zasoby potrzebne do wdrożenia dobrych praktyk projektowania architektury oprogramowania

Aby zbudować przyzwoitą architekturę oprogramowania, wystarczy zatrudnić zespół inżynierów i projektantów UX/UI. W zależności od technologii możesz potrzebować:

• programistów Ruby on Rails
• koderów React 
• inżynierów React Native 
• itd.

Przy bardziej szczegółowej strukturze zespołu warto rozważyć pozyskanie programistów o różnym poziomie doświadczenia.

Junior

Początkujący architekt IT z mniej niż rocznym doświadczeniem w zawodzie powinien mieć już następujące umiejętności:

• umieć zbierać wymagania dotyczące tworzenia oprogramowania;
• brać udział w projektowaniu systemów informatycznych;
• samodzielnie umieć zaprojektować część architektury usług;
• przygotowywać dokumentację techniczną;
• uczestniczyć w organizacji końcowych testów kompleksów programowych.

Mid

Do obowiązków specjalisty z 1-3-letnim doświadczeniem dochodzi więcej odpowiedzialności i samodzielności. Architekt oprogramowania na poziomie mid ma też elastyczne kompetencje, które w przyszłości pomogą mu kierować zespołem programistycznym.

Programista musi więc:

• mieć umiejętność opisywania architektury systemu;
• umieć projektować architekturę Enterprise, Solution i Technical;
• tworzyć artefakty architektoniczne;
• umieć pracować z architekturą mikroserwisową;
• mieć dobre umiejętności komunikacyjne.

Senior

Specjalista z ponad trzyletnim doświadczeniem kieruje już zespołem. Ma rozwinięte umiejętności menedżerskie i negocjacyjne w kontakcie z klientem, a przy tym zna dobre praktyki projektowania architektury oprogramowania.

Wymagania zawodowe wyglądają następująco:

• znajomość języków programowania;
• analiza dokumentów projektowych pod kątem kompletności i braku sprzeczności;
• analiza decyzji, wprowadzanie zmian w toku prac;
• kontrola jakości kodu;
• kontrola jakości i terminów.

Podsumowanie

Głównym celem architektury jest zdefiniowanie wymagań, które wpływają na strukturę aplikacji. Dobrze przemyślana architektura zmniejsza ryzyko biznesowe związane z budową rozwiązania technicznego i buduje most między wymaganiami biznesowymi a technicznymi.

Choć stosowanie dobrych praktyk projektowania architektury oprogramowania może wydawać się dla konkretnej firmy kosztowne, utrzymanie aplikacji i zapewnienie działania funkcji będzie znacznie droższe.

Dlatego od pierwszego dnia warto pracować z doświadczonymi specjalistami (czy to programistami Flutter czy inżynierami JavaScript) od pierwszego dnia.