Szczegółowa klasyfikacja diagramów architektury
Proces Typ
Wyrażenie graficzne
Myślenie Typ
Wyrażenie strukturalne
Notatki Typ
Efektywne wyrażanie
Mapa drzewa
Schemat nawiasów
Tryb domyślny
Współpraca wielu użytkowników w czasie rzeczywistym z linkami do udostępniania
Automatyczne generowanie grafiki z tekstu z ulepszaniem stylu
Wbudowane motywy z pełną personalizacją
Obsługa ikon, obrazów, etykiet, formuł LaTeX, bloków kodu, linków, załączników
Eksport: PNG, VISIO, PDF, SVG | Import: VISIO, Mermaid
Przechowywanie w chmurze w czasie rzeczywistym, synchronizacja wielourządzeniowa, historia wersji i bezpieczeństwo danych
Architektura aplikacji dotyczy tylko tego, które systemy aplikacyjne i platformy są potrzebne do osiągnięcia celów biznesowych, bez rozważania, jakie technologie muszą być używane w całym procesie budowy. Architektura techniczna natomiast zajmuje się wymaganiami technicznymi wynikającymi z architektury aplikacji i obejmuje wybór technologii oraz wyjaśnienie relacji między różnymi kluczowymi technologiami.
Tak. Diagram architektury mikroserwisów jest specyficznym rodzajem diagramu architektury technicznej, który pokazuje, jak podzielić system na niezależne, wdrażalne mikroserwisy. Mówiąc prosto, diagram architektury mikroserwisów to zastosowanie diagramu architektury technicznej w kontekście mikroserwisów.
Diagram architektury produktu służy jako podstawa do kierowania diagramem architektury technicznej. Dlatego kolejność rysowania diagramów architektury technicznej i produktu zazwyczaj polega na stworzeniu najpierw diagramu architektury produktu, a następnie diagramu architektury technicznej. Diagram architektury produktu koncentruje się na funkcjach produktu, modułach i interakcjach użytkowników, podczas gdy diagram architektury technicznej koncentruje się na konkretnych rozwiązaniach technicznych, komponentach systemu i metodach interakcji potrzebnych do wdrożenia tych funkcji.
Diagram architektury technicznej obejmuje cztery wymiary: architekturę sprzętową, architekturę oprogramowania, architekturę pośrednią i architekturę danych. Nie tylko wizualnie przedstawia moduły systemu, komponenty i ich zależności, ale także zapewnia ustrukturyzowany widok przez cały cykl analizy wymagań, projektowania architektury i utrzymania wdrożenia, zapewniając spójne zrozumienie projektu systemu w zespole.
Musi być odzwierciedlone. Diagram powinien wyraźnie wskazywać granice narażenia systemu, firewalle, WAF, domeny bezpieczeństwa, SSO, kontrolę dostępu itp., w przeciwnym razie diagram nie ma wartości referencyjnej podczas przeglądów bezpieczeństwa.
Tak. Zaleca się zanotowanie używanych frameworków (takich jak SpringBoot, Kafka), języków (takich jak Java, Python), baz danych (takich jak MySQL, MongoDB) itp. w kluczowych komponentach. Jest to pomocne przy rozwoju, operacjach, wyborze technologii i rozwiązywaniu problemów.
Kierunek strzałek powinien być wyraźnie narysowany, a metoda komunikacji (taka jak REST, gRPC, MQ, WebSocket) powinna być zanotowana obok strzałek. W przeciwnym razie informacje w diagramie są trudne do zrozumienia, zwłaszcza podczas projektowania interfejsów i analizy wydajności.
Tak, zaleca się użycie 'warstwy zarządzania systemem' lub 'warstwy platformy operacyjnej' do wyświetlania tych komponentów, takich jak Jenkins, Prometheus, ELK, SkyWalking itp.
