Architectural style-lar: qısa bələdçi

Architectural style component-lərin adlandırılmış, təkrarlanan düzülüşü və onların qarşılıqlı əlaqə qaydalarıdır. Style-lar faydalıdır, çünki məlum trade-off-larla gəlirlər. Təhlükəlidirlər, çünki dəblə gəlirlər.

Bu fəsildə geniş yayılmış style-lar xüsusiyyətlər paketi kimi təsvir olunur. Heç biri tövsiyə edilmir; hamısı harasa uyğundur.

Layered (n-tier)

Component-lər üfüqi layer-lərdə düzülür və hər layer yalnız özündən aşağıdakını çağıra bilər: presentation, business logic, persistence. Bu, əksər framework-lərin və əksər dərsliklərin default style-ıdır.

Güclü tərəfləri: anlamaq asandır, kadr tapmaq asandır, UI məsələlərini data kodundan kənarda saxlayan ayrılığı təmin edir.
Zəif tərəfləri: layer-lər pass-through-ya çevrilməyə meyllidir, buna görə sadə dəyişiklik hər layer-ə toxunur. Layering domain strukturu haqqında heç nə demir, ona görə böyük layered application səliqəli etiketlənmiş mərtəbələri olan big ball of mud-a çevrilir.
Uyğun gəldiyi hal: tək komandası və hələ tam başa düşülməmiş domain-i olan kiçik və orta ölçülü application-lar.

Modular monolith

Tək deployable unit, amma daxildə explicit interface-lərə və enforce edilən dependency qaydalarına malik module-lara bölünüb. Module-lar öz data-sına sahibdir; module-lararası müraciət shared cədvəllər vasitəsilə deyil, published API-lər vasitəsilə gedir.

Güclü tərəfləri: monolith-in bütün operational sadəliyi üstəgəl service-lərin təşkilati üstünlüklərinin çoxu. Module-lararası refactoring distributed migration deyil, compiler-in yoxladığı dəyişiklikdir.
Zəif tərəfləri: intizam tooling ilə enforce edilməlidir, əks halda boundary-lər aşınır. Scaling kobuddur: hər şeyi birlikdə scale edirsiniz.
Uyğun gəldiyi hal: əksər məhsullar, əksər vaxtlarda. Həmçinin sonradan bölünə biləcək sistem üçün ən yaxşı başlanğıc nöqtəsidir, çünki module-lar namizəd service-lərə çevrilir.

Microservice-lər

Hər biri öz data-sına sahib olan və network üzərindən əlaqə saxlayan çoxsaylı independently deployable service-lər. Təşkiledici prinsip independent deployability-dir: komanda digər komandalarla koordinasiya etmədən release edə bilməlidir.

Güclü tərəfləri: komandalar bir-birindən decouple olur. Hər service uyğun texnologiyadan istifadə edə, ayrıca scale oluna və (belə design olunubsa) hər şeyi çökdürmədən fail ola bilər.
Zəif tərəfləri: network artıq application-ınızın içindədir. Latency, partial failure, versioning, distributed transaction-lar, observability və local development — hamısı çətinləşir. Güclü platform dəstəyi olmayan microservice architecture-i geri qaytarılmayan vergidir.
Uyğun gəldiyi hal: release cadence-ləri həqiqətən toqquşan bir neçə komandası və çoxlu service-i işlətmək üçün platform yetkinliyi olan təşkilatlar.

Yaxşı köhnəlmiş bir qayda: komanda boundary-lərini çəkə bilmirsinizsə, service boundary-lərini çəkməyə hazır deyilsiniz.

Burada sadalanan çətinliklərin hər birinə sonrakı fəsillərdə ayrıca baxılır: partial failure-a Fəsil 11-də, distributed transaction-lara Fəsil 12-də, deployment-ə Fəsil 14-də, observability-yə isə Fəsil 15-də.

Event-driven

Component-lər digərlərinin subscribe olduğu event-lər emit edərək, adətən broker vasitəsilə, əlaqə saxlayır. İki alt-növ var: notification — event nəyinsə baş verdiyini deyir, detalları gedib soruşursunuz — və event-carried state transfer — event data-nın özünü daşıyır, consumer-lərin geri müraciət etməsinə ehtiyac qalmır.

Güclü tərəfləri: producer-lər consumer-lər haqqında bilmir, ona görə yeni consumer əlavə etmək producer-ə heç nəyə başa gəlmir. Temporal decoupling: consumer işləməyə bilər və sonradan yetişə bilər.
Zəif tərəfləri: control flow görünməzdir. "Order yerləşdirilən zaman nə baş verir?" sualı codebase boyu subscription-ları izləməyi tələb edir. Eventual consistency product adamlarına izah edilməlidir.
Uyğun gəldiyi hal: çoxlu downstream reaksiyaları olan workflow-lar, təşkilati boundary-lər arasında integration, audit-ağırlıqlı domain-lər.

Hexagonal (ports and adapters)

Domain logic mərkəzdə oturur və xarici dünya haqqında heç nə bilmir. Ehtiyac duyduğu hər şey üçün port-lar (interface-lər) müəyyən edir; adapter-lər bu port-ları konkret texnologiyalar üçün implement edir: REST adapter-i, Postgres adapter-i, test double.

Güclü tərəfləri: domain logic infrastructure-suz test oluna bilir. Database-i və ya message broker-i dəyişmək adapter dəyişikliyidir.
Zəif tərəfləri: sadə CRUD application-ın ehtiyac duyduğundan daha çox indirection. Komandalar bəzən adapter-ləri qurur və ortaya heç bir logic qoymağı unudur.
Uyğun gəldiyi hal: domain logic-in dəyərli hissə, infrastructure-un isə təsadüfi olduğu sistemlər.

Pipeline / pipes-and-filters

Data müstəqil processing stage-lərinin ardıcıllığından keçir. Hər stage input-u oxuyur, transform edir, output-u yazır. Unix shell pipeline-ları, ETL job-ları və compiler-lər hamısı bu formadadır.

Güclü tərəfləri: stage-lər composable və ayrı-ayrılıqda test oluna biləndir. Parallelism təbii şəkildə ortaya çıxır.
Zəif tərəfləri: interactive davranışa və ya stage-lər arasında shared state tələb edən hər şeyə zəif uyğun gəlir.
Uyğun gəldiyi hal: data processing, media transcoding, build sistemləri.

Serverless / function-as-a-service

Kod event-lərlə trigger olunan ayrı-ayrı function-lar şəklində deploy olunur, scaling və lifecycle-ı platform idarə edir.

Güclü tərəfləri: idle cost sıfırdır, avtomatik scaling, minimal operational səth.
Zəif tərəfləri: cold start-lar, vendor-ə məxsus execution model-ləri, execution müddəti limitləri və architecture-in heç kimin review edə bilmədiyi console-da bir-birinə bağlanmış yüz xırda function-a çevrilmə meyli.
Uyğun gəldiyi hal: spiky və ya aşağı həcmli workload-lar, glue code, event handler-lər.

Seçim

Style-lar compose olur. Modular monolith hər module-un içində hexagonal strukturdan istifadə edə və serverless reporting pipeline-ına event-lər emit edə bilər. Sual heç vaxt "hansı style?" deyil, "mənə hansı xüsusiyyətlər lazımdır və bu komanda üçün onları ən aşağı qiymətə hansı style verir?" sualıdır.

Üç sual əksər style mübahisələrini kəsib keçir:

Neçə komandanın independent deploy etməyə ehtiyacı var? Cavab birdirsə, microservice-lərə ehtiyacınız yoxdur.
Load-un forması necədir? Sabit load uzunmüddətli process-lərə, spiky load elastic olanlara üstünlük verir.
Complexity haradadır? Domain logic-dədirsə, mərkəzi qoruyun (hexagonal). Integration-dadırsa, flow-ları explicit edin (event-lər, pipeline-lar).

Hazırkı sisteminiz haqqında suallar

Sisteminiz adlandırıldığından fərqli olaraq əslində hansı style-dadır?
Style-ın məlum zəif tərəflərindən hansılarını hazırda hiss edirsiniz?
Bir deployable unit-i bölməli və ya birləşdirməli olsaydınız, hansı olardı və niyə?