Please enable JavaScript.
Coggle requires JavaScript to display documents.
Tydzień 1 - Coggle Diagram
Tydzień 1
Metryki
Metryka jest kwantyfikacją drivera, zapewnia jednoznaczne jego zrozumienie
przykład metryki testowalności - procent krytycznych procesów biznesowych możliwych do przetestowania z pominięciem UI
Wartości metryk - określ aktualną wartość, limit , cel oraz ideał aby być w stanie mierzyć postęp/regres
Metryka musi być : jednoznaczna , mierzalna, łatwo dostępna
Przykłady metryk : czas kompilacji aplikacji , czas potrzebny do wdrożenia , procesy biznesowe pokryte testami
metryki jakościowe (dążymy do polepszenia wyników), dłużne (dążymy do niepogorszenia wyników/ nieprzekroczenia limitów) i łączne
-
rodzaje
-
biznesowe (procesowe)
-
przykłady : liczba złożonych zamówień , średnia wartość koszyka , czas spędzony na stronie
-
-
-
-
korzyści
-
budują zaufanie - jeśli powiesz że skróciłeś czas budowania systemu o 30% i przyniosło to taki a taki zysk to z pewnością dostaniesz czas w przyszłości na podobne rzeczy
Architektura
-
Architekt tworzy projekt koncepcyjny a programista wykonawczy, który jest wykonywany przez interpreter lub kompilator
-
jako
zestaw decyzji
architect types
enterprise
skupia się na celach a nie rozwiązaniach problemu, celem jest przechowywanie danych poprawnie, rozwiązanie zostawiamy devom
-
application
-
jakiego stylu arch. użyć, jakiej technologii użyć, jak ustrukturyzować naszą aplikację
zakres komponentu skupiałby się już na wzorcach projektowych, bibliotekach itp
solution
jak rozwiązać konkretne problemy biznesowe; rozpoznaje wymagania biznesowe, wie jakie są możliwości działu IT i dostosowuje rozwiązanie
-
opis struktury
zbiór elementów, relacji między tymi elementami i ich właściwości
proces
OODA
obserwacja, orientacja , decyzje , działanie
-
-
architekt rozumie otoczenie w ktorym dziala, aplikuje narzędzia i podejmuje decyzje i obserwuje efekt w działaniu systemu
-
-
zmniejsza ryzyko kosztownych pomyłek , umożliwia sprawną współpracę, tworzy słownictwo , umożliwia całościowe postrzeganie systemu
Architektura to proces podejmowania decyzji w oparciu o drivery architektoniczne skwantyfikowane za pomoca metryk dzieki temu budujemy spojne zrozumienie problemu wsrod wszystkich interesariuszy naszego systemu. Na podstawie tych informacji podejmujemy decyzje ktore ksztaltuja nasz system
Diagramy C4
-
C2
Diagram kontenerów - kontenery mają nazwy, odpowiedzialność, wybrane technologie, interakcje
container - środowisko uruchomieniowe dla komponentów czyli np. serwer aplikacyjny , baza danych
C3
Diagram komponentów
Pokazuje rozdział odpowiedzialności na poziomie jednego kontenera, pozwala promować reużywalność komponentów i strukturyzowaać wiedzę na poziomie jednego kontenera
diagram zawiera komponenty opisane przez nazwę (np. resetowanie hasła), odpowiedzialność (pozwala na wygenereowanie url do resetu hasła) , wybraną technologię (Spring MVC Rest Controller), interakcje (prezentowane strzałkami oraz opisuj sync/async)
coponent - zespół współpracujących ze sobą klas, które tworzą swego rodzaju kontrakt
-
info
common abstraction over notation,
C4 można tworzyć używając UML, nie wyklucza innych narzędzi
-
można stworzyć też C5, wystarczy że dodamy kilka systemów
pokazują głównie podział logiczny ale nie ma przeszkód by stworzyć podział infrastrukturalny z pokazaną redundancją etc
ograniczenia
model statyczny, nie pokazuje jak przebiegają requesty/response'y
-
Drivers
Drivery architektoniczne
Odpowiadają na pytanie dlaczego ten system powstał w takim a nie innym kształcie, skąd ta technologia, dlaczego relacyjna baza danych ?
klasy driverów
-
jakościowe
skalowalnosc, rozszerzalnosc, bezpieczny, ma zapewniac audyt, konfigurowalnosc i obserwowalnosc
jeśli nie pomyślimy o nich zawczasu , dodanie ich w locie może być bardzo kosztowne
-
-
cele projektowe
byc moze robisz prototyp , wted baza danych w pamieci moze byc dobrym wyjsciem, ale docelowy prijekt juz na takim rozwiazaniu moze sie nie oprzec
ich odkrywanie oszczędza czas i pieniądze, zawęża przestrzeń możliwego rozwiązania, zbliża do wyboru, uświadamia realne potrzeby
źródłem informacji o driverach są interesariusze - finansujacy projekt, klienci, CTO etc
-
Drivery nie muszą dotyczyć całego systemu, skalowalność może być wymagana dla kluczowych procesów biznesowych a dostępność raportowania może być inna niż przyjmowania zamówień
Nie są stałe w czasie, z jego biegiem może okazać się że rozwijalność i testowalność nie jest tak ważna jak utrzymywalność i dostępność
-
ADR
struktura
Tytuł: czego dotyczy decyzja
kontekst: jakie są znane drivery ?
decyzja: wybór i uzasadnienie
konsekwencje : znane skutki
inne możliwe rozwiązania : dlaczego nie zostały wybrane
-
-
