Model C4: Wizualizacja architektury oprogramowania jak „Google Maps dla kodu”

„Model C4 pomaga zespołom jasno, spójnie i na odpowiednim poziomie szczegółowości przekazywać architekturę oprogramowania.”
— Simon Brown

The Model C4 (Context, Kontenery, Komponenty, Kod) to hierarchiczny, powiększalny framework do dokumentowania architektury oprogramowania. Jest zaprojektowany tak, aby był przyjazny dla programistówzgodny z Agile, oraz czytelny — przechodząc dalej po zatłoczonych, statycznych schematach „pudełek i linii”.

Zezwala zespołom na:

  • Skuteczne przekazywanie architektury między stakeholderami technicznymi i nie-technicznymi.

  • Zachowywanie spójnej dokumentacji poddanej kontroli wersji.

  • Skupianie się na tym, co ma znaczenie na każdym poziomie abstrakcji.


🔍 Kluczowe abstrakcje modelu C4

The Ultimate Guide to C4 Model Visualization with Visual Paradigm's AI Tools - ArchiMetric

Poziom Koncepcja Cel
Poziom 1: Kontekst System i Osoby Kto korzysta z systemu? Jak oddziałuje z otoczeniem?
Poziom 2: Kontenery Jednostki wdrażalne Jakie są wysokopoziomowe komponenty techniczne (aplikacje, bazy danych, interfejsy API)?
Poziom 3: Komponenty Grupowania logiczne Jak jest zorganizowana funkcjonalność wewnątrz kontenera?
Poziom 4: Kod (opcjonalnie) Klasy, interfejsy, metody Szczegóły implementacji — zazwyczaj generowane przez środowiska IDE.

✅ Kluczowy zasadaPowiększaj tylko wtedy, gdy to konieczne.Zacznij szeroko, a następnie przejdź do szczegółów.


🧩 Kluczowe elementy i relacje

Element Opis Przykład
Osoba Człowiek działający lub użytkownik KlientAdministratorZewnętrzne API
System oprogramowania System dostarczający wartość System internetowego bankowości
Kontener Jednostka wdrażalna (czas wykonania lub wdrażalna) Aplikacja internetowa, mikroserwis, baza danych, funkcja bezserwerowa
Składnik Logiczna grupa powiązanych funkcjonalności Moduł uwierzytelnianiaPrzetwarzacz płatnościFacade głównego komputera
Związki Łączności w języku potocznym między elementami "Używa""Wywołuje""Odczytuje/Zapisuje""Zależy od"

💬 Użyj język naturalny do określenia związków. Unikaj nieprecyzyjnych słów takich jak „łączy się z”.


📊 Poziomy modelu C4 z przykładami PlantUML

📌 Wszystkie przykłady używają biblioteki C4-PlantUML w celu zapewnienia spójności i automatyzacji.


1. Diagram kontekstu systemu (Poziom 1)

Kto korzysta z systemu? Z jakimi zewnętrznymi systemami się komunikuje?

🎯 Odbiorcy: Niekierownicy techniczni, właściciele produktów, kierownicy.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
LAYOUT_WITH_LEGEND()
tytuł Diagram kontekstu systemu dla internetowego bankowości

Osoba(klient, "Klient", "Osoba korzystająca z bankowości osobistej")
System(system_bankowy, "System bankowości internetowej", "Zezwala klientom na przeglądanie kont i dokonywanie płatności")
System_Zew(główny_komputer, "System bankowości głównego komputera", "Przechowuje wszystkie dane bankowe główne")

Związek(klient, system_bankowy, "Używa")
Związek_R(system_bankowy, główny_komputer, "Pobiera informacje o koncie z")
@enduml

✅ Skupienie się: Zakres i granice systemu.


2. Diagram kontenerów (Poziom 2)

Jakie są główne komponenty technologiczne i ich technologie?

🎯 Odbiorcy: Architekci, programiści, inżynierowie DevOps.

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

Person(customer, "Klient", "Klient indywidualny bankowości internetowej")
System_Boundary(c1, "System bankowości internetowej") {
    Container(web_app, "Aplikacja internetowa", "Java, Spring MVC", "Dostarcza zawartość użytkownikowi")
    Container(api_app, "Aplikacja API", "Java, Spring Boot", "Dostarcza funkcjonalność przez JSON/HTTPS")
    ContainerDb(db, "Baza danych", "Baza danych relacyjna", "Przechowuje dane użytkownika")
}

System_Ext(mainframe, "System główny bankowości", "Przechowuje wszystkie dane podstawowe bankowości")

Rel(customer, web_app, "Używa", "HTTPS")
Rel(web_app, api_app, "Wywołuje", "JSON/HTTPS")
Rel(api_app, db, "Odczytuje/Zapisuje", "JDBC")
Rel(api_app, mainframe, "Używa", "XML/HTTPS")
@enduml

✅ Skupienie się: Wybór technologiigranice wdrażaniaprzepływy danych.


3. Diagram komponentów (Poziom 3)

Jak jest zbudowana wewnętrznie aplikacja API?

🎯 Odbiorcy: Programiści, kierownicy techniczni, kierownicy zespołów.

@startuml
!include https://static.visual-paradigm.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml
LAYOUT_WITH_LEGEND()
title Diagram komponentów aplikacji API w bankowości internetowej

Container(api_app, "Aplikacja API", "Java, Spring Boot")
ContainerDb(db, "Baza danych", "Baza danych relacyjna")
System_Ext(mainframe, "System główny bankowości")

Container_Boundary(api_boundary, "Aplikacja API") {
    Component(sign_in, "Kontroler logowania", "Kontroler MVC", "Zezwala użytkownikom na logowanie")
    Component(security, "Komponent zabezpieczeń", "Spring Security", "Obsługuje uwierzytelnianie")
    Component(mainframe_facade, "Facade systemu głównego", "DAO", "Komunikuje się z systemem głównym")

    Rel(sign_in, security, "Używa")
    Rel(security, db, "Odczytuje/Zapisuje")
    Rel(sign_in, mainframe_facade, "Używa")
    Rel(mainframe_facade, mainframe, "Używa")
}
@enduml

✅ Skupienie się: Struktura wewnętrznaodpowiedzialnościzależności.


4. Diagram kodu (Poziom 4 – opcjonalny)

Szczegóły implementacji: klasy, interfejsy, metody.

🎯 Odbiorcy: Deweloperzy, recenzenci kodu.

⚠️ Nie zaleca się rysowania ręcznie — najlepiej generowane za pomocą IDE (np. IntelliJ, VS Code) przy użyciu narzędzi do automatycznego tworzenia diagramów.

Przykład (uproszczony):

@startuml
class SignInController {
  +signIn()
  +validateCredentials()
}

class SecurityComponent {
  +authenticate()
  +generateToken()
}

class MainframeFacade {
  +fetchAccountData()
  +sendTransaction()
}

SignInController --> SecurityComponent : Używa
SecurityComponent --> Database : Odczytuje/Zapisuje
MainframeFacade --> MainframeAPI : Używa
@enduml

✅ Najlepsza praktyka: Automatyzuj ten poziom przy użyciu narzędzi takich jak PlantUML + wtyczki IDE.


✅ Najlepsze praktyki i kluczowe zasady

Zasada Dlaczego to ma znaczenie
Iteracyjne dopasowanie Zacznij od kontekstu → dodawaj szczegóły tylko wtedy, gdy są potrzebne. Unikaj nadmiernego dokumentowania.
Diagramy jako kod Przechowuj .puml pliki w Git. Pozwala na wersjonowanie, CI/CD, współpracę i porównywanie zmian.
Zawieraj legendę Zawsze wyjaśnij symbole, kolory i konwencje (np. Czerwony = ZewnętrznyNiebieski = Wewnętrzny).
Skup się na komunikacji Diagramy powinny informować, a nie wrażać. Prostota > kompletność.
Używaj diagramów „Obrazu systemu” Pokaż, jak wiele systemów współpracuje w obrębie organizacji.
Używaj diagramów „Dynamicznych” Dodaj diagramy sekwencji, aby pokazać zachowanie w czasie wykonywania (np. przepływ logowania).
Ogranicz zakres odpowiedzialnie Diagram składników musi być ograniczony w jednym kontenerze. Nie mieszkaj kontenerów!

🛠 Narzędzia i ekosystem

  • PlantUML + Biblioteka C4-PlantUML – Darmowe, oparte na tekście, kontrolowane wersjami.

  • Visual ParadigmLucidchartDraw.io – Obsługa C4 poprzez szablony.

  • Wtyczki IDE – Automatyczne generowanie diagramów C4 z kodu (np. IntelliJ + wtyczka PlantUML).

  • Integracja CI/CD – Generuj diagramy jako część procesu budowania.


📚 Zasoby i dalsza lektura


🎯 Ostateczna myśl

Model C4 nie dotyczy tworzenia doskonałych schematów — chodzi o opowiadanie właściwej historii na odpowiednim poziomie szczegółowości.

Użyj go do:

  • Szybsze włączanie nowych programistów.

  • Wyrównanie zespołów pod kątem granic systemu.

  • Komunikowanie się z zaangażowanymi stronami bez żargonu.

  • Rozwój dokumentacji architektury wraz z kodem.


✅ Porada: Zaczynaj od Diagram kontekstu systemu schematu. Następnie rozwijaj model wraz z rozwijającymi się potrzebami zespołu — jak budowanie mapy ulica po ulicy.


Daj znać, jeśli chcesz:

  • Dostępna do pobrania wersja PDF tego przewodnika

  • Szablonowy repozytorium z diagramami C4 w Git

  • Skrypty automatyzacji do generowania diagramów C4 z kodu

  • Porównanie z innymi modelami (np. 4+1 View, Zachman)

Miłego rysowania schematów! 🖥️📘