Problem: bir diaqram, beş fərqli auditoriya
Komanda "arxitektura" adlı lövhə şəklini miras alır. Orada müxtəlif ölçülü qutular, yazısız oxlar, verilənlər bazası ola biləcək bir bulud şəkli və heç kimin xatırlamadığı legend var. Product owner sistemin nə etdiyini anlamır, yeni developer kodu hara yazacağını bilmir, əməliyyat mühəndisi nəyi monitorinq edəcəyini seçə bilmir. Diaqram eyni anda bütün suallara cavab verməyə çalışır və heç birinə cavab vermir.
C4 modeli arxitektura diaqramlarına xəritə kimi yanaşır. Ölkə, şəhər və küçə xəritəsi eyni yerin fərqli miqyaslı çertyojlarıdır və hər birinin öz auditoriyası var. C4 dörd miqyas müəyyən edir: context, container, component və code. Bu, alət və ya fayl formatı deyil; hansı məlumatın hansı diaqrama düşdüyünü həll etmə üsuludur. İstənilən alətdə, hətta düz mətndə də çəkmək olar.
Dörd səviyyə
Səviyyə 1, system context. Sizin sistem bir qutu kimi göstərilir, ətrafında isə onunla işləyən insanlar və xarici sistemlər durur. Texnologiya seçimləri yoxdur. Auditoriya hamıdır, texniki olmayan tərəflər də daxil. Cavab verdiyi sual: bu sistem nədir, kim istifadə edir və nədən asılıdır?
Səviyyə 2, containers. Burada "container" Docker demək deyil. Ayrıca işə düşən və ya deploy olunan vahiddir: Spring Boot servisi, single-page tətbiq, PostgreSQL bazası, message broker, batch job. Hər qutuda texnologiya və məsuliyyət yazılır. Auditoriya developerlər, əməliyyat komandası və arxitektlərdir. Sual: hərəkət edən hissələr hansılardır, bir-biri ilə necə danışır və data harada saxlanır?
Səviyyə 3, components. Bir container-in içinə baxırıq və əsas tikinti bloklarını göstəririk. Məsələn, Spring Boot servisi üçün REST controller-lər, OrderService, ödəniş client-i və repository qatı. Auditoriya həmin container üzərində işləyən developerlərdir. Bu səviyyəni yalnız strukturu aydın olmayan container-lər üçün çəkin.
Səviyyə 4, code. Class və ya cədvəl diaqramları. Demək olar həmişə koddan tələb üzrə generasiya olunur və əllə saxlamağa nadir hallarda dəyər.
Nümunə: kiçik rezervasiya sistemi
Onlayn rezervasiya platforması üçün 1-ci səviyyə:
+--------------+ books +-----------------------+
| Customer |---------------->| Booking Platform |
| [Person] | | [Software System] |
+--------------+ | Lets customers book |
| and pay for slots |
+--------------+ manages | |
| Venue Staff |---------------->| |
| [Person] | +-----------------------+
+--------------+ | |
card v v emails
payments +---------+ +-----------+
| Payment | | Email |
| Provider| | Service |
| [Ext.] | | [Ext.] |
+---------+ +-----------+2-ci səviyyədə Booking Platform qutusunun içinə baxırıq:
Customer Venue Staff
| |
v HTTPS v HTTPS
+--------------------------------+
| Web App [React SPA] |
+--------------------------------+
| JSON/HTTPS
v
+--------------------------------+ +-------------------+
| Booking API |---->| Payment Provider |
| [Spring Boot 3, Java 21] | | [External, REST] |
| Validates, books, orchestrates | +-------------------+
+--------------------------------+
| |
| JDBC | publishes BookingConfirmed
v v
+-----------+ +-----------+ +-----------------------+
| Database | | Broker |---->| Notification Worker |
| [Postgres]| | [Kafka] | | [Spring Boot] |
+-----------+ +-----------+ | Sends emails |
+-----------------------+Nəyin olduğuna baxın: hər qutunun tipi və texnologiyası mötərizədədir, hər oxun istiqaməti və felı ya protokolu var, sistemin sərhədi aydındır. Nəyin olmadığına da baxın: class adları yoxdur, cloud provayder ikonları yoxdur, heç bir məna daşımayan bəzək rəngləri yoxdur.
Oxucunun vaxtına qənaət edən qeyd qaydaları
- Hər elementə ad, tip (Person, Software System, Container, Component) və bir cümləlik məsuliyyət verin.
- Hər oxu niyyətlə ("sifariş göndərir") və container səviyyəsində protokolla ("JSON/HTTPS") yazın.
- Zəngi kimin başlatdığını göstərən tək istiqamətli oxlara üstünlük verin. İki tərəfli ox əsl asılılığı gizlədir.
- Rəng və ya forma işlədirsinizsə, legend əlavə edin və məna bütün diaqramlarda eyni qalsın.
- Hər diaqramın başlığı səviyyəni və əhatəni desin, məsələn "Container diagram for Booking Platform".
- Diaqramı təxminən on iki elementdən artıq etməyin. Çoxdursa, şriftı kiçiltmək əvəzinə içəri zoom edərək bölün.
- Səviyyələri qarışdırmayın. Eyni diaqramda insanın yanında verilənlər bazası cədvəli varsa, səviyyə sürüşüb.
Əvvəlcə auditoriyanı seçin
Çəkməzdən əvvəl bir cümlə yazın: "Bu diaqram [kimə] [nəyi] həll etməyə kömək edir." Context diaqramı sponsora sistemin hansı xarici tərəflərdən asılı olduğunu görməyə kömək edir. Container diaqramı yeni developerə funksiyanın hara aid olduğunu tapmağa, əməliyyat mühəndisinə isə nəyin monitorinq edilməli olduğunu müəyyən etməyə kömək edir. Component diaqramı bir container-ə sahib komandaya refaktorinqi planlamağa kömək edir. Cümləni tamamlaya bilmirsinizsə, diaqrama hələ ehtiyac yoxdur. Bu vərdiş həm də detalın nə vaxt dayanacağını göstərir.
Diaqramları aktual saxlamaq
Diaqramlar dəyişikliyin baş verdiyi yerdən kənarda yaşayanda köhnəlir. Üç təcrübə kömək edir.
Birincisi, onları mətn şəklində kodun yanında, eyni repository-də saxlayın. Beləcə container-i dəyişən Pull Request onun diaqramını da dəyişir. Mətn əsaslı formatlar review üçün əlverişlidir və diff-i təmizdir.
İkincisi, struktur dəyişikliklərini (yeni servis, yeni datastore, yeni xarici inteqrasiya) "done" tərifinə diaqramın yenilənməsini də daxil edin. Gündəlik kod dəyişiklikləri diaqram yenilənməsi tələb etmir, məhz buna görə container səviyyəsində dayanmaq lazımdır.
Üçüncüsü, diaqramları Architecture Decision Record-lərlə əlaqələndirin. Diaqram nəyin olduğunu göstərir, ADR isə niyə belə olduğunu izah edir. Birlikdə onboarding suallarının çoxuna cavab verirlər.
Tez-tez edilən səhvlər
- Container-i Docker image kimi başa düşmək. C4-də container öz prosesi və ya data saxlayıcısı olan deploy vahididir, paketlənmə üsulundan asılı olmayaraq.
- Hər şeyi bir anda çəkmək. İstifadəçini, servisi, class-ı və serveri göstərən diaqram kolajdır, görünüş deyil.
- Yazısız oxlar. "Çağırır" məlumat deyil. "Qiymətləri REST ilə oxuyur" məlumatdır.
- İnfrastruktur detallarını yanlış səviyyədə göstərmək. Load balancer, subnet və replica-lar ayrıca deployment diaqramına aiddir.
- 4-cü səviyyəni əllə saxlamaq. Bir neçə günə köhnəlir; ya generasiya edin, ya atlayın.
- Auditoriyanın olmaması. Diaqramın kim üçün olduğunu deyə bilmirsinizsə, nəyi çıxaracağınızı da seçə bilməzsiniz.
Əlavə görünüşlər
Dörd səviyyə əsas xəritədir, amma bütün sualları örtmür. Zamanla davranışı göstərmək üçün sequence və ya dynamic diaqramı, serverlərin və mühitlərin yerini göstərmək üçün deployment diaqramı əlavə edin. Bu əlavə görünüşlər də eyni qaydalara tabedir: aydın başlıq, auditoriya, etiketli oxlar. Onları da yalnız həqiqətən sual yaranan axınlar üçün çəkin, məsələn ödəniş və ya geri qaytarma axını.
Güzəştlər və nə vaxt əziyyətə dəyməz
C4 ortaq lüğət verir, amma zamanla davranışı təsvir etmir; ödəniş axını üçün sequence diaqramı hələ də daha yaxşıdır. Həmçinin qeyri-funksional tələbləri və deployment topologiyasını özü tutmur. Bir nəfərin sahib olduğu tək servisli prototip üçün context eskizi və README-də bir abzas kifayətdir. Modelin qiyməti intizamdır: kimsə diaqramlara sahib çıxmalı və onların nə vaxt köhnəldiyini həll etməlidir.
Yoxlama siyahısı
- Texniki olmayan insanın bir dəqiqəyə anlaya biləcəyi context diaqramı varmı?
- Container diaqramı hər deploy vahidini və data saxlayıcısını göstərirmi?
- Hər oxun istiqaməti və yazısı varmı?
- Hər diaqramın başlığında səviyyə və əhatə yazılıbmı?
- Diaqramlar repository-dədir və Pull Request ilə dəyişirmi?
- Adlı sahibi və yenilənmə üçün razılaşdırılmış trigger varmı?
Növbəti addım
Strukturun arxasındakı əsaslandırmanı ADR yazmaq məqaləsindəki qaydada qeyd edin. Arxitektlərin diaqramlardan gündəlik işdə necə istifadə etdiyini solution architect rolu məqaləsində görün və ya Solution Architect roadmap-ını izləyin.