Wprowadzenie do modelu C4: szybki przewodnik

Wprowadzenie

Model model C4, opracowany przez Simona Browna, oferuje strukturalny podejście do rysowania diagramów architektury oprogramowania, składający się z czterech różnych poziomów, które stopniowo przybliżają architekturę systemu oprogramowania. Każdy poziom zapewnia unikalny punkt widzenia i spełnia określone cele w dokumentowaniu i komunikowaniu architektury oprogramowania. Przyjrzyjmy się czterem poziomom modelu C4:

1. Diagram kontekstu systemu

Zakres:Jeden system oprogramowania.

Główne elementy:System oprogramowania w zakresie.

Elementy wspierające: Ludzie (np. użytkownicy, aktorzy, role, postacie) oraz systemy oprogramowania (zewnętrzne zależności) bezpośrednio połączone z systemem oprogramowania w zakresie.

Odbiorcy: Wszyscy, zarówno osoby techniczne, jak i nietechniczne, zarówno wewnętrzne, jak i zewnętrzne dla zespołu tworzącego oprogramowanie.

Cel: Diagram kontekstu systemu oferuje początkowy, ogólny obraz architektury systemu oprogramowania. Służy jako punkt wyjścia do dokumentacji architektonicznej, zapewniając kompleksowy punkt widzenia systemu w jego szerokim środowisku. Na tym diagramie system oprogramowania jest przedstawiony jako centralny prostokąt otoczony użytkownikami i innymi systemami zewnętrznymi, z którymi się komunikuje. Nacisk kładziony jest na ludziach i systemach oprogramowania, a nie na szczegółach technicznych, takich jak technologie czy protokoły.

Zalecany dla większości zespołów: Tak.

Kluczowe cechy:

• Oferuje widok z góry na system.
• Podkreśla interakcje między systemem a jego użytkownikami/systemami zewnętrznymi.
• Idealny do komunikacji z nietechnicznymi stakeholderami.
• Poziom szczegółowości jest świadomie utrzymywany niski.

2. Diagram kontenerów

Zakres:Jeden system oprogramowania.

Główne elementy: Kontenery w obrębie systemu oprogramowania w zakresie (np. aplikacje internetowe po stronie serwera, aplikacje jednostronicowe, bazy danych itp.).

Elementy wspierające: Ludzie i systemy oprogramowania bezpośrednio połączone z kontenerami.

Właściwy odbiorca:Osoby techniczne wewnętrzne i zewnętrzne wobec zespołu tworzącego oprogramowanie, w tym architekci oprogramowania, programiści oraz personel operacyjny/supportowy.

Cel:Diagram kontenera głębiej analizuje system oprogramowania, skupiając się na jego strukturze najwyższego poziomu oraz rozkładzie odpowiedzialności między kontenerami. Kontenery reprezentują oddzielnie uruchamiane lub wdrażane jednostki, takie jak aplikacje internetowe lub bazy danych. Ten diagram również wyróżnia kluczowe wyboru technologiczne i ilustruje sposób komunikacji między kontenerami. Jest to cenna narzędzie zarówno dla programistów, jak i personelu operacyjnego/supportowego.

Zalecany dla większości zespołów: Tak.

Kluczowe cechy:

• Skupia się na architekturze systemu oprogramowania.
• Ilustruje kontenery i ich wzajemne interakcje.
• Wyróżnia wybrane technologie.
• Przydatny dla stakeholderów technicznych.
• Nie uwzględnia szczegółów związanych z wdrażaniem, takich jak klastrowanie lub równoważenie obciążenia.

3. Diagram składników

Zakres:Jeden kontener.

Główne elementy:Składniki znajdujące się w obrębie kontenera.

Elementy wspierające:Kontenery (w obrębie systemu oprogramowania w zakresie), osoby oraz systemy oprogramowania bezpośrednio połączone z składnikami.

Właściwy odbiorca:Architekci oprogramowania i programiści.

Cel:Diagram składników oferuje szczegółowy obraz struktury wewnętrznej kontenera. Dzieli kontener na jego główne elementy strukturalne, znane jako składniki. Te składniki odpowiadają za konkretne zadania wewnątrz kontenera i są związane z detalami technologicznymi i implementacyjnymi. Ten diagram jest szczególnie przydatny dla architektów oprogramowania i programistów, którzy potrzebują zrozumienia szczegółowych aspektów architektury kontenera.

Zalecany dla większości zespołów: Nie, twórz diagramy składników tylko wtedy, gdy przynoszą wartość, a rozważ automatyzację ich tworzenia w przypadku dokumentacji o długim okresie istnienia.

Kluczowe cechy:

• Skupia się na strukturze wewnętrznej kontenera.
• Określa składniki, ich odpowiedzialności oraz szczegóły implementacji.
• Skierowany do stakeholderów technicznych.
• Nie zawsze jest konieczny i powinien być używany ostrożnie, gdy przynosi wartość dokumentacji.

4. Diagram kodu

Zakres: Jedna komponenta.

Główne elementy: Szczegółowy kod i artefakty techniczne wewnątrz konkretnej komponenty.

Elementy wspierające: Komponenty (w obrębie kontenera w zakresie), kontenery (w obrębie systemu oprogramowania w zakresie) oraz osoby i systemy oprogramowania bezpośrednio połączone z komponentami.

Odbiorcy: Osoby o wysokim poziomie technicznym, zazwyczaj programiści i osoby głęboko zaangażowane w kod.

Cel: Ostatni poziom modelu C4, diagram kodu, powiększa się jeszcze bardziej, aby zaprezentować szczegółowy obraz kodu konkretnej komponenty. Ten diagram bada rzeczywisty kod źródłowy, struktury klas i szczegóły implementacji technicznej wewnątrz komponentu. Jest szczególnie przydatny dla programistów, którzy muszą pracować nad konkretną komponentą lub rozumieć jej wewnętrzne zasady działania.

Zalecane dla większości zespołów: Rzadko stosowane w praktyce. Zazwyczaj nie tworzy się diagramów kodu, ponieważ poziom szczegółowości, jaki zapewniają, jest zazwyczaj objęty dokumentacją kodu i środowiskami programistycznymi.

Kluczowe cechy:

• Skupia się na rzeczywistym kodzie źródłowym i artefaktach technicznych.
• Zapewnia bardzo szczegółowy obraz implementacji komponenty.
• Zapewnia szczegółowy obraz implementacji komponenty.
• Rzadko stosowane w praktyce z powodu wysokiego poziomu szczegółowości, ponieważ ta informacja jest zazwyczaj dostępna bezpośrednio w kodzie.

Wnioski

Cztery poziomy modelu C4 zapewniają zorganizowaną hierarchię dokumentowania i komunikowania architektury oprogramowania, zaczynając od ogólnego omówienia na diagramie kontekstu systemu i stopniowo przechodząc do rzeczywistego kodu na diagramie kodu. Te diagramy są przeznaczone dla różnych odbiorców – od niefachowych stakeholderów, którzy korzystają z ogólnego obrazu, po bardzo technicznych programistów, którzy potrzebują szczegółowych wglądów na poziomie kodu. Wykorzystując model C4, architekci oprogramowania i zespoły programistyczne mogą skutecznie przekazywać złożone projekty architektoniczne i wspierać lepsze zrozumienie oraz współpracę wewnętrznie i na zewnątrz organizacji.