Software architecture

Diagramy architektury pomagają w łatwiejszym zrozumieniu i komunikowaniu się na temat oprogramowania między różnymi grupami osób, w tym między klientami a zespołem programistycznym.

Diagramy pozwalają na przełożenie wymagań biznesowych na techniczny opis oprogramowania. Są one szczególnie przydatne dla osób nietechnicznych, takich jak klienci i właściciele produktów, którzy nie rozumieją kodu.

Diagramy architektury pozwalają na szybki feedback, m.in. ze strony programistów oraz innych architektów, co pozwala na szybsze nanoszenie poprawek i ulepszanie rozwiązania. Diagramy architektury pozwalają też na konsultację rozwiązania z innymi architektami i członkami zespołu, co z kolei umożliwia skupienie się na problemie biznesowym, zamiast na niuansach technologicznych.

Dla kogo są diagramy architektury

Diagramy rysuję się dla róznych odbiorócw:

• klienci, product ownerzy - generalnie ludzie nie techniczni, którzy nie rozumieją kodu. Gdy przychodzi do prezentacji architektury dla ludzi, którzy muszą ją “klepnąć” to prezentowanie diagramów ma kluczowe znaczenie. Diagram jest to swego rodzaju pomost pomiędzy wymaganiami biznesowymi, a kodem

• programiści na diagramie widać, czy rozwiązanie zaprojektowane przez architekta ma sens i łączy się w całość. Programiści mogą zgłosić swój feedback, a architekt nanieść poprawki (czasami błyskawicznie, nawet na tym samym spotkaniu z programistami). Gdy pracujesz od razu na kodzie, to naniesienie zmian nie jest tak proste jak na diagramach.

• architekci tak, architekt rysuje diagram dla samego siebie. Diagram od razu pokazuje, czy rozwiązanie ma sens czy nie. Operowanie na poziomie diagramów jest szybsze niż na poziomie kodu i pozwala skupić się na problemie biznesowym, zamiast na niuansach technologicznych. Poza tym konsultacja rozwiązania z innymi architektami i członkami zespołu jest prostsza gdy można pokazać rysunek

Typy i poziomy diagramów

W internecie możesz znaleźć przykłady wielu rodzajów diagramów takich jak, deployment architecture diagram, integrations diagram etc. Na diagramie możesz tak naprawdę narysować wszystko i ważniejsze jest to jak to na rysujesz. Ja w swojej pracy używam techniki rysowania diagramów nazwanej c4 model

c4 model

W modelu c4 systemy opisuje się na czterech różnych poziomach:

1. context

2. container (nie myl z kontenerami dockera)

3. component

4. code

Poziomy te różnią się szczegółowością. Można je porównać do mapy, którą można przybliżać. Im bardziej przybliżona mapa tym więcej szczegółów widzisz. Analogicznie jest na diagramach c4, gdzie na poziomie contextu widzisz ogólny zarys systemu i to co ten system robi.

Na poziomie container widzisz jakie elementy zawiera ten system. Tutaj zobaczysz już np. bazę danych, aplikację web, aplikacje backendową itp.

Te dwa poziomy są idealne do pokazywania systemu ludziom nietechnicznym, ponieważ pokazują jak system wygląda i jak ma działać, bez wchodzenia w szczegóły implementacyjne. (Poziom container może wymagać już pewnej wiedzy technicznej, poziom Context powinien być zrozumiały nawet dla ludzi totalnie nietechnicznych)

Kolejne dwa poziomy pokazują więcej szczegółów technicznych i są świetne do dyskusji z programistami. Na tym poziomie każdy container jest przybliżony tak, że widać z jakich komponentów jest zbudowany.

Na ostatnim poziomie czyli code, mamy już samo “mięso” dla programistów takie jak klasy, interfejsy, relacje, są to już typowe diagramy UML.

Co ciekawe ten poziom zazwyczaj nie jest wymagany ani rysowany.

Więcej o modelu c4 przeczytasz tutaj: https://c4model.com/

Diagramy sekwencji

Kolejnym type diagramów, które są bardzo przydatne w zrozumieniu jak coś ma działać są diagramy sekwencji. Du tworzenia tych diagramów używam tego narzędzia:

https://sequencediagram.org/

Zalety diagramów sekwencji

• są liniowe i pokazują jak coś działa z góry do dołu i od lewej do prawej. Poszczególne kroki można ponumerować i wtedy łatwo je prezentować, oraz o nich dyskutować

• można na nich pokazać nawet bardzo trudne scenariusze

• działają na każdym poziomie (w notacji c4)

• są świetne do pracy zespołowej

• służą też później za dokumentację

Narzędzia do diagramów

Oprócz wspomnianego przeze mnie wcześniej sequencediagram.org polecam narzędzie Miro do rysowania diagramów. Jest proste w użyciu, posiada darmową wersję, która jest dobra na start.

Problem z diagramami

Niestety, istnieją również pewne wady związane z korzystaniem z diagramów architektury. Niektóre z nich to:

• Możliwość przekłamywania rzeczywistości - diagramy architektury mogą ukazywać jedynie część rzeczywistości, a nie całego systemu. Może to prowadzić do błędnej interpretacji, co z kolei może prowadzić do błędów projektowych lub implementacyjnych.

• Trudność w aktualizacji - diagramy architektury są statyczne i nie odzwierciedlają zmian w systemie, które zdarzają się często. Aktualizacja diagramów może być czasochłonna i pracochłonna.

• Brak standardów - brak standardów dotyczących tworzenia diagramów architektury może prowadzić do trudności w interpretacji diagramów przez różne osoby.

• Złożoność - diagramy architektury mogą stać się bardzo skomplikowane i trudne do zrozumienia, szczególnie dla osób, które nie są zaznajomione z systemem.

Architect astronauts

Termin ten odnosi się do “architektów”, którzy poświęcają zbyt dużo czasu i energii na tworzenie doskonałych diagramów i planów, zamiast na faktyczną pracę nad kodem i rozwiązywaniem problemów biznesowych.

Innymi słowy, architekt skupia się bardziej na projektowaniu niż na implementacji, co może prowadzić do opóźnień i kosztów projektu oraz do niezadowolenia klientów. Trzeba pamiętać, że diagramy są narzędziem pomocniczym, a nie celem samym w sobie.

Innym problemem może być to, że stereotypowi architekci to często ludzie, którzy tak bardzo odeszli od programowania, że mogą być delikatnie mówiąc odklejeni od rzeczywistości. Jak ktoś kto nie pracuje na co dzień z kodem może projektować w oderwaniu od rzeczywistości system?

Architekt nie może siedzieć gdzieś w kącie i rysować diagramów, które później zostaną olane i na nic się nie zdadzą. Komunikacja i ciągłe zbieranie feedbacku, a najlepiej praca zespołowa z deweloperami sprawią, że diagramy dadzą wartość dla Twojego zespołu. Mówię nie dla architektów astronautów!

Nawet najlepiej narysowany diagram może zdać się na nic z jednego prostego powodu: nie zostanie wytłumaczony należycie innym, co za tym idzie nie zostanie zrozumiany, ani wykorzystany w pracy.

Podsumowanie

Diagramy architektury są narzędziem, które ułatwiają zrozumienie i komunikację na temat oprogramowania między różnymi grupami osób. Ich zaletą jest możliwość łatwego przetłumaczenia wymagań biznesowych na techniczny opis oprogramowania, co jest szczególnie przydatne dla osób, które nie są związane z branżą technologiczną, jak np. klienci i właściciele produktów.

Co więcej, diagramy pozwalają na szybki feedback, co umożliwia szybsze wprowadzanie poprawek i ulepszanie rozwiązania. Jednak należy pamiętać, że diagramy powinny stanowić narzędzie pomocnicze, a nie celem samym w sobie.

Przy korzystaniu z diagramów warto mieć na uwadze ich pewne wady, takie jak możliwość przekłamywania rzeczywistości, trudność w aktualizacji, brak standardów czy złożoność. Dlatego ważne jest, aby korzystać z diagramów w sposób właściwy i skupić się przede wszystkim na pracy nad kodem oraz rozwiązywaniu problemów biznesowych.

A czy Ty używasz diagramów w swojej codziennej pracy?