Software Architecture nədir (və nə deyil)

On mühəndisdən software architecture-in nə olduğunu soruşsanız, on iki cavab alarsınız. Bəziləri qutular və oxlardan ibarət diaqramı göstərəcək. Bəziləri hansısa framework-ün adını çəkəcək. Bir neçəsi isə səmimi şəkildə deyəcək: "senior nə qərar veribsə, odur." Bu cavabların heç biri yanlış deyil, amma heç biri də üzərində karyera qurmaq üçün kifayət qədər faydalı deyil.

Bu fəsildə işlək bir tərif təklif olunur və, eyni dərəcədə vacib olaraq, architecture-in nə olmadığı sadalanır.

İşlək tərif

Software architecture dəyişdirilməsi baha başa gələn design decision-ların və bu qərarları doğuran əsaslandırmanın məcmusudur.

Bu cümlənin üç hissəsi xüsusi yük daşıyır.

Qərarlar. Architecture sənəd və ya diaqram deyil. Diaqramlar qərarları çatdırmaq üçün vasitədir. Üç database əvəzinə bir dənə olması, payment service-in synchronous işləməsi, mobil tətbiqin warehouse API-sinə birbaşa müraciət etməsinə icazə verilməsi — bunlar kimsə çəkib-çəkməməsindən asılı olmayaraq architecture-dir.

Dəyişdirilməsi baha başa gələn. Dəyişən adı da design decision-dır, amma onu dəyişmək saniyələr çəkir. Message broker-in, tenancy model-in və ya consistency guarantee-nin seçimi isə sistem production-a çıxandan sonra geri qaytarmaq üçün aylar tələb edir. Qərarı "design"dan "architecture"ə qaldıran məhz geri qaytarma dəyəridir. Qeyd edək ki, bu, dəqiq sərhəd deyil, sürüşkən şkaladır və zamanla yerini dəyişir: ikinci həftədə ucuz dəyişdirilə bilən seçimi ikinci ildə dəyişmək qorxulu ola bilər.

Əsaslandırma. Niyəsi olmayan qərar sadəcə folklordur. Komandalar elə sistemlər miras alır ki, orada heç kimin toxunmağa cəsarət etmədiyi strukturlar var, çünki qəribəliyin qəsdən olub-olmadığını heç kim xatırlamır. Əsaslandırmanı qoruyub saxlamaq növbəti komandaya constraint-in hələ də qüvvədə olub-olmadığına qərar vermək imkanı verir.

Architecture nə deyil

Texnologiya siyahısı deyil

"Biz Kubernetes, Postgres və React istifadə edirik" — bu, materiallar siyahısıdır, architecture deyil. İki komanda eyni stack-dən istifadə edib tamamilə əks xüsusiyyətlərə malik sistemlər qura bilər. Architecture hissələrin bir-biri ilə necə danışmasına icazə verildiyində, hər birinin nəyə cavabdeh olduğunda və onlardan biri sıradan çıxanda nə baş verdiyindədir.

Mərhələ deyil

"Əvvəl architecture, sonra kodlaşdırma" şəklindəki waterfall mənzərəsi əsasən təqdimat slaydlarında yaşayır. Real sistemlər fasiləsiz olaraq design olunur. İlkin qərarlar səhnəni qurur, amma hər əhəmiyyətli feature sualları yenidən ortaya qoyur: bu, mövcud boundary-lərə sığır, yoxsa hansısa boundary-nin yanlış yerdə olduğunu üzə çıxarır?

Şəxs deyil

Qüllədən diaqramları aşağı ötürən "architect" elə sistemlər yaradır ki, onlar həftələr içində diaqramlardan uzaqlaşır. Architecture kiminsə sahiblənməli olduğu bir məsuliyyətdir və ona sahib olan şəxs reallıqla niyyətin ayrıldığını görmək üçün koda kifayət qədər yaxın qalmalıdır.

Fundamental gərginlik

Hər architecture qərarı bir xüsusiyyəti digərinə qarşı dəyişir. Daha sürətli write, yoxsa daha sadə read. Independent deployability, yoxsa end-to-end consistency. Daha az hərəkətli hissə, yoxsa yalnız bir hot spot-u ayrıca scale etmək imkanı.

Mücərrəd mənada "yaxşı" architecture yoxdur. Yalnız müəyyən prioritetlər toplusu üçün yaxşı olan architecture-lər var. Növbəti fəslin hər hansı strukturdan əvvəl quality attribute-lərə həsr olunmasının səbəbi də budur: nəyi optimize etdiyinizi bilmədən strukturu qiymətləndirə bilməzsiniz.

Kitabın qalan hissəsini necə oxumalı

Fəsil 2 quality attribute-lərin lüğətini qurur və sisteminiz üçün hansılarının həqiqətən əhəmiyyətli olduğunu necə müəyyən etməyi göstərir.
Fəsil 3 geniş yayılmış architectural style-ları nəzərdən keçirir və hər birinə tövsiyə kimi deyil, trade-off paketi kimi yanaşır.
Fəsil 4 decomposition-dan bəhs edir: xətləri harada çəkməli və yaxşı boundary-ni pisindən necə fərqləndirməli.
Fəsil 5 qərarların qeydə alınmasını əhatə edir ki, əsaslandırma onu verən insanlardan daha uzun yaşasın.

İlk beş fəsil düşüncə tərzini qurur. Qalan fəsillər həmin düşüncə tərzini böyük miqyaslı sistemlərin konkret problemlərinə tətbiq edir:

Fəsil 6–7 requirement-ləri rəqəmlərə çevirir: capacity estimation, availability, SLO-lar və error budget.
Fəsil 8–10 sistemin əsas hissələrini nəzərdən keçirir: API-lər, load balancer, cache, message broker kimi building block-lar və data qatı.
Fəsil 11–13 distributed sistemlərin çətin hissələrinə keçir: failure-lara davamlılıq, service-lər arası data və data pipeline-lar.
Fəsil 14–15 sistemin production-dakı həyatından bəhs edir: deployment strategiyaları və observability.
Fəsil 16 bütün kitabı bir nümunə sistemin dizaynında birləşdirir.

Hər fəsil artıq tanıdığınız bir sistem haqqında verə biləcəyiniz qısa suallar toplusu ilə bitir. Architecture müşahidə etmə bacarığıdır və müşahidə təcrübə ilə cilalanır.

Hazırkı sisteminiz haqqında suallar

Sisteminizdəki hansı üç qərarı bu gün geri qaytarmaq ən baha başa gələrdi?
Onların hər biri üçün yazılı əsaslandırmanı harasa tapa bilirsinizmi?
Tapa bilmirsinizsə, kimdən soruşmalı olardınız və o şəxs hələ də şirkətdədirmi?