Różnice między decyzjami architektonicznymi a technicznymi

Czym są decyzje architektoniczne?

Decyzje architektoniczne to wybory o szerokim zasięgu, które kształtują strukturę, zachowanie i kluczowe atrybuty jakościowe systemu (tzw. wymagania niefunkcjonalne - NFRs). Wymagania niefunkcjonalne określają jak system powinien działać a nie co robi. Atrybutami jakościowymi mogą być: skalowalność, wydajność, bezpieczeństwo, czy łatwość utrzymania. Są to decyzje trudne i kosztowne do zmiany w późniejszym etapie projektu. Często są podejmowane na wczesnym etapie cyklu życia oprogramowania i mają długoterminowe konsekwencje.

Charakterystyka decyzji architektonicznych:

Decyzje architektoniczne chatakteryzują się następującymi cechami:

• Wysoki wpływ: Dotyczą fundamentalnych aspektów systemu.
• Wysoki koszt zmiany: Wycofanie lub zmiana decyzji jest skomplikowana, czasochłonna i kosztowna.
• Długoterminowe konsekwencje: Kształtują system na lata.
• Dotyczą wymagań niefunkcjonalnych: Bezpośrednio wpływają na to, jak system działa pod obciążeniem, w jakim stopniu jest bezpieczny, jak łatwo go rozwijać oraz utrzymywać.

Przykłady decyzji architektonicznych:

• Wybór paradygmatu architektury: Monolit vs. Mikroserwisy vs. Architektura sterowana zdarzeniami (EDA).
• Wybór głównej technologii bazy danych: Relacyjna (np. PostgreSQL, MySQL) vs. NoSQL (np. MongoDB, Cassandra) dla kluczowych danych systemu.
• Strategii komunikacji między komponentami/serwisami: Synchroniczna (np. REST, gRPC) vs. Asynchroniczna (np. RabbitMQ, Kafka).
• Wybór platformy chmurowej i jej kluczowych usług: Decyzja o oparciu systemu o AWS, Azure czy GCP i wykorzystaniu ich specyficznych usług.
• Określenie głównych mechanizmów autentykacji i autoryzacji w całym systemie (np. OAuth2, OpenID Connect).

Czym są Decyzje Techniczne?

Decyzje techniczne, często nazywane implementacyjnymi, mają węższy zakres i dotyczą sposobu realizacji konkretnych funkcjonalności lub komponentów w ramach już ustalonej architektury. Są łatwiejsze i tańsze do zmiany, a ich wpływ jest zazwyczaj lokalny.

Charakterystyka decyzji technicznych:

Jako decyzje techniczne możemy określić takie które posiadają następujące cechy:

• Lokalny wpływ: Dotyczą konkretnego modułu, komponentu lub zadania.
• Niższy koszt zmiany: Zmiana biblioteki czy algorytmu jest zazwyczaj prostsza.
• Krótkoterminowe konsekwencje: Wpływają na bieżącą implementację.
• Odpowiadają na pytanie "jak": np. jak zaimplementować daną funkcjonalność.

Przykłady decyzji technicznych:

• Wybór konkretnej biblioteki do realizacji zadania: Np. wybór między Guzzle a Symfony HttpClient do obsługi żądań w jednym z serwisów.
• Struktura kodu wewnątrz modułu/komponentu: Np. organizacja klas i metod w ramach konkretnego modułu.
• Wybór algorytmu dla specyficznej funkcji: Np. decyzja o użyciu konkretnego algorytmu sortowania dla listy wyników.
• Formatowanie kodu: Ustalenie i stosowanie standardów kodowania (choć to często jest decyzja na poziomie zespołu/organizacji, staje się "techniczna" w codziennym stosowaniu ponieważ jest łatwe i niekosztowne w zmianie).

Porównanie