Model C4 - model dokumentowania architektury

Twórcą metodyki C4 jest Simon Brown – zaproponował on czterostopniowy model dokumentowania architektury, ukierunkowany na odbiorcę. Model ten charakteryzuje podejście dość przejrzyste, z niewieloma zasadami oraz elementami semantycznymi, jakie powinny być stosowane podczas tworzenia architektury systemu. Ze względu na wyżej wskazane cechy, podejście takie harmonizuje ze zwinnymi metodykami tworzenia oprogramowania.

Model C4 opiera się o rozdzielenie opisu architektury na cztery warstwy abstrakcji. Każda z nich odgrywa inną rolę. Posiada zróżnicowane cechy i odmienne zawiera odmienne szczegóły. Dzięki temu może być kierowana do programistów, architektów, PO itd. Czyli osób o odmiennych rolach w zespole czy firmie. 

Wyróżniamy jak nazwa wskazuje 4 warstwy:

• C1 - Context System - spojrzenie na system z lotu ptaka. Celem jest pokazanie otoczenia, w jakim działa nasz system.
• C2 - Containers - pokazujemy kontenery wchodzące w skład systemu. Pojedynczy kontener to osobno wdrażana i autonomiczna jednostka
• C3 - Components - schodząc niżej na poziom każdego kontenera wizualizujemy komponenty wchodzące w skład danego kontenera
• C4 - Code - na koniec tworzony jest diagram reprezentujący kod. Może być to znany z UMLa diagram klas.

W pewnym sensie można zauważyć tutaj podejście od ogółu do szczegółu.

 

 

Model C4 wprowadza organizację do wizualizacji architektury. Poszczególne warstwy nie tylko dzielą system ale stanowią także zlepek odrębnych informacji. Razem to całość schowana pod płaszczykami warstw. Osobno to wystarczający opis fragmentu z całego systemu. Mniej szczegółów oznacza mniej trudności ze zrozumieniem.

 

Ze szczegółami systemu, zapoznajesz się poprzez zagłębianie krok po koku w elementy i warstwy architektury modelu.

 

 

Poziom 1 – Kontekst Systemu

Punktem wyjściowym do tworzenia architektury jest kontekst, w jakim dany system działa.
Na poziomie tym przedstawiony jest modelowany system, będący centralnym elementem diagramu, a także jego interakcje z zewnętrznymi aktorami lub systemami. 

Szczegóły nie są tutaj ważne, ponieważ jest to widok pomniejszony, pokazujący duży obraz krajobrazu systemu. Należy skupić się na ludziach (aktorach, rolach, osobach itp.) i systemach oprogramowania, a nie na technologiach, protokoły i inne szczegóły niskiego poziomu. Jest to rodzaj diagramu, który można pokazać osobom nietechnicznym.

Poziom 2 – Diagram Kontenerów

Wchodząc w głąb systemu uwidacznia się niższy poziom abstrakcji – struktura systemu oparta o kontenery, które odwzorowują rozkład odpowiedzialności elementów systemu realizujących procesy biznesowe. Kontenerem może być osobno uruchamiana bądź instalowana jednostka, wykonująca kod lub zapisująca dane.

Typowymi elementami występującymi na tym poziomie abstrakcji są aplikacje mobilne, aplikacje webowe, bazy danych, czy kolejki systemowe. Co więcej, aspekty techniczne – jak typ magazynu danych czy protokoły użyte w komunikacji pomiędzy kontenerami – są nieodzowną częścią tego poziomu.
Diagram zawiera również systemy zewnętrzne, widoczne na poprzednim poziomie, ilustrując komunikację kontenerów z otoczeniem (światem zewnętrznym).

Głównym odbiorcą tego diagramu jest szeroko rozumiany DevOps – osoby odpowiadające za rozwój, utrzymanie lub zapewnienie jakości systemu – oraz architekci i programiści.

 

Poziom 3 – Komponenty

Na tym poziomie architektury staramy się przedstawić wnętrze pojedynczego kontenera składającego się z komponentów. W podejściu C4 komponent odzwierciedla „prawdziwą abstrakcję” na poziomie kodu, czyli zgrupowanie kodu mające wspólną bazę, znaczenie czy funkcjonalność. 

Na tym poziomie widoczne są aspekty technologiczne odnoszące się do implementacji komponentu, czyli użyty framework, czy język programowania.

 

Poziom 4 – Klasy

Pojedyncze klasy są tematem najniższego poziomu architektury C4. 

Zidentyfikowane w poprzednim kroku komponenty posiadają wewnętrzną strukturę, którą można rozłożyć na klasy lub inne artefakty. Modelując duże i złożone systemy, komponenty mogą być tak dużą jednostką architektoniczną, że na tym poziomie uwypukla się architektura aplikacji – rozkład na warstwy lub inne style architektoniczne.

Zważywszy na fakt, że grupą docelową tego poziomu są programiści i architekci, czyli osoby operujące na kodzie, poziom ten można zwizualizować za pomocą diagramu klas, który jest składową języka UML.

Jest to opcjonalny poziom szczegółowości i często jest dostępny na żądanie z narzędzi, takich jak IDE.

Materiały:

https://modelc4.pl/ 

https://c4model.com/

https://mrdev.pl/10-powodow-dla-ktorych-warto-znac-model-c4 

https://tomaszsokol.pl/wizualizacja-architektury-zgodnie-z-modelem-c4-podejscie-praktyczne/