Robert C. Martin wspomina w swojej książce „Czysta architektura” o takim podziale, że architektura to wysokopoziomowe sprawy, a projekt to szczegóły i sprawy niższego rzędu. Architekt robi architekturę, a programiści robią projekt. Idąc dalej można zaryzykować stwierdzenie, że architekt to wielmożny gość, który jest ponad programistami.
Rzeczywistość nie jest tak kontrowersyjna. Architektura i projekt to jedno i to samo. Architekt to też programista, często najlepszy, który prowadzi zespół w wytyczonym kierunku. Architekt też dalej pisze kod, na pewno mniej niż wcześniej, pomimo tego musi to dalej robić, żeby nie wypaść z gry i móc rozmawiać technicznie z programistami.
Każdy system składa się z wysokopoziomowych decyzji i niskopoziomowych szczegółów. Jest to nierozłączne. Bardzo ważne jest tutaj, żeby system powstawał przy współpracy architektów i programistów, a nie w izolacji.
Pomyśl i projekcie domu, w którym architekt projektuje niemal każdy element od od kształtu, wyglądu, rozkładu pomieszczeń, aż do tego, gdzie mają być rozmieszczone gniazdka. Są to właśnie wysokopoziomowe decyzje.
Na etapie budowy takiego domu, gdy nie ma już architekta, to inwestor sam może zdecydować, jakie dokładnie mają być te gniazdka albo jaki tynk ma być położony na ścianach. To są właśnie niskopoziomowe szczegóły,
Czym więc jest ta architektura?
Przeanalizujmy kolejny znany podział. Podział systemu na wartości:
- jak system ma działać, co ma robić (zachowanie)
- jak łatwo można ten system zmienić (architektura)
Z powyższego podziału można wywnioskować, że architektura opisuje jak łatwo można zmienić dany system. Sprowadza się to do tego, że architektura definiuje koszt zmiany, koszt całego systemu i nakład pracy potrzebny do jego wdrożenia.
Czyli architektura to opis systemu mający na celu minimalizację nakładu pracy potrzebnego na wdrożenie i późniejsze utrzymanie systemu.
Cel architektury
Celem architektury jest zachowanie otwartych możliwości jak najdłużej. Architektura koncentruje się na wysokopoziomowych decyzjach, nie na frameworkach, bazach danych, protokołach komunikacyjnych i narzędziach. Celem architektury jest wyznaczenie reguł pozwalających na realizację wymagań biznesowych. Architektura skupia się na regułach, a nie na szczegółach. Celem dobrej architektury jest ułatwienie:
- realizacji przypadków użycia
- wdrożenia systemu
- konserwacji i utrzymania systemu
- dalszego rozwoju systemu
- łatwej zmiany wcześniej podjętych decyzji
Składowe architektury
Architekturę można podzielić na kilka składników:
- charakterystyki architektury (nazywane inaczej atrybuty jakościowe) — są to kryteria sukcesu systemu np. scalability, observability, performance, availability.
- Decyzje architektoniczne — decyzje określające jak system ma działać.
- Design principles — różnią się od decyzji architektonicznych tym, że są to wskazówki jak coś powinno być zrealizowane. Nie są to twarde reguły jak decyzje architektoniczne.
Podsumowanie
Jeśli miałbyś zapamiętać jedno zdanie z tego tekstu, to zapamiętaj to:
Architektura to opis systemu, a celem architektury jest minimalizacja nakładu pracy potrzebnego na wdrożenie i utrzymania tego systemu. Dobra architektura to taka, która ułatwia pracę nad oprogramowaniem i zachowuje otwarte możliwości jak najdłużej jest to możliwe.
Jeśli chciałbyś zagłębić się w sprawy opisane w tym artykule, to zachęcam do przeczytania książek podlinkowanych w źródłach poniżej. Kupując przez te linki wesprzesz też mojego bloga/newsletter.
