Əsas məzmuna keç
DevScallix
← ProqramlarPlanlaşdırılır

Senior-dan Architect-ə: sistem dizaynı və arxitektura liderliyi

12 həftəlik, instruktor müşayiətli planlaşdırılan syllabus: tələblər və keyfiyyət atributlarından, data və inteqrasiya arxitekturasından, təhlükəsizlik və əməliyyat xərclərindən texniki liderliyə qədər. Proqramın sonunda real ödəniş sistemi kimi bir ssenari üzrə arxitekturanı müdafiə edirsiniz. Sıra və dərinlik qrupa uyğun dəyişə bilər; proqram iş və ya vəzifə vəd etmir.

Bu proqram planlaşdırılır və hələ cədvələ salınmayıb. Tarix, qrup və qəbul açıq elan olunmayıb; müraciət qəbul etmirik. Maraq bildirin və ya konsultasiya istəyin: proqram planlaşdırıldıqda sizinlə əlaqə saxlayarıq.

Müddət
12 həftə
Canlı dərslər
həftədə 2 dərs, hər biri 90 dəqiqə
Mərhələ
4 mərhələ

12 həftə

Həftə-həftə tədris planı

Planlaşdırılan tədris planıdır: sıra və dərinlik qrupa uyğun dəyişə bilər. İş təminatı və ya vəzifə vədi deyil.

01 · 1–3-cü həftələr

Əsaslar: tələblər, üslublar, sənədləşdirmə

Mərhələnin məqsədi: Qeyri-müəyyən biznes tələbini ölçülə bilən keyfiyyət atributlarına çevirmək, arxitektura üslubunu əsaslandırmaq və qərarı C4 + ADR ilə sənədləşdirmək.

  1. Həftə 1

    Arxitektorun rolu, tələblər və keyfiyyət atributları

    • Arxitektor nə qərar verir və nəyə cavabdehdir
    • Funksional tələb, keyfiyyət atributu, məhdudiyyət
    • Quality attribute scenario və utility tree
    • C4 Level 1 (System Context) və ADR-ə giriş

    Laboratoriya: Squad-lar ödəniş bildirişi xidməti üçün tələbləri çıxarır, 5 quality attribute scenario yazır və C4 kontekst diaqramı çəkir.

    Tapşırıq: Fərdi: seçdiyiniz case üçün ADR-001 və C4 kontekst diaqramı olan repozitoriya.

  2. Həftə 2

    Arxitektura üslubları: modular monolith, microservices, event-driven

    • Modular monolith: sərhədlər, module qaydaları, nə vaxt kifayətdir
    • Microservices: komanda sərhədi, deployment müstəqilliyi, paylanmış sistemin xərci
    • Event-driven: event vs command, eventual consistency, delivery zəmanətləri
    • Üslub seçimi üçün qərar meyarları

    Laboratoriya: Eyni case üçün üç üslubda kobud dekompozisiya çəkib hər birinin xərc/fayda cədvəlini doldurun.

    Tapşırıq: ADR-002: üslub seçimi, rədd edilmiş alternativlər və geri dönmə şərtləri ilə.

  3. Həftə 3

    C4, ADR və arxitektura sənədləşdirməsi

    • C4 Level 2-3: container və component diaqramları
    • Diaqram qaydaları: legend, başlıq, əlaqə istiqaməti
    • ADR həyat dövrü: proposed, accepted, superseded
    • Fitness function-lar və arxitekturanın avtomatik yoxlanması

    Laboratoriya: Qarşılıqlı diaqram review: hər squad başqasının C4 container diaqramını oxuyur və 5 sual yazır.

    Tapşırıq: Fərdi: C4 Level 2 diaqramı + ən azı bir fitness function təsviri (məsələn, module asılılıq qaydası).

Yoxlama nöqtəsi: Seçilmiş case üçün tələblər sənədi, C4 Level 1-2 diaqramları və ən azı üç ADR (üslub seçimi daxil).

02 · 4–6-cü həftələr

Miqyas və data arxitekturası

Mərhələnin məqsədi: Yükü və tutumu hesablamaq, data üçün partitioning/replication seçimlərini əsaslandırmaq və CQRS-in nə vaxt lazım olduğunu müəyyən etmək.

  1. Həftə 4

    Miqyaslanma və tutum hesablaması

    • Back-of-the-envelope hesablama: RPS, saxlama, bandwidth
    • Pik yük, p95/p99 gecikmə və headroom
    • Horizontal vs vertical scale, stateless dizayn
    • Cache qatları və invalidation riskləri

    Laboratoriya: Case üçün gündəlik və pik yükü hesablayın, ilk darboğazı tapın və yük testi planı yazın.

    Tapşırıq: Fərdi: fərziyyələri açıq göstərən capacity estimation cədvəli (1 səhifə).

  2. Həftə 5

    Data arxitekturası: partitioning, replication, consistency

    • Partition açarı seçimi və hot partition problemi
    • Replication: sync/async, replica lag, failover
    • Consistency modelləri və CAP/PACELC praktikada
    • Tranzaksiya sərhədləri və idempotentlik

    Laboratoriya: Ledger (mühasibat jurnalı) üçün data modeli: partition açarı, replica topologiyası və failover ssenarisi.

    Tapşırıq: ADR-003: data saxlama və partitioning qərarı, nəticələri və risk qeydləri ilə.

  3. Həftə 6

    Mesajlaşma, CQRS və event sourcing: nə vaxt əsaslandırılır

    • Queue vs log (Kafka tipli) fərqi və seçim meyarları
    • Outbox pattern və at-least-once ilə idempotent consumer
    • CQRS: oxu/yazı modellərini nə vaxt ayırmaq lazımdır
    • Event sourcing-in xərci: replay, schema təkamülü, GDPR

    Laboratoriya: Ödəniş statusu axını üçün outbox + idempotent consumer dizaynı və 'CQRS lazımdırmı?' qərar iclası.

    Tapşırıq: Fərdi: CQRS üçün 'bəli' və ya 'xeyr' ADR-i; rədd etmək də məqbul cavabdır, əsaslandırılmalıdır.

Yoxlama nöqtəsi: Capacity estimation cədvəli, data modeli ilə partitioning/replication qərarı və CQRS üçün əsaslandırılmış (və ya rədd edilmiş) ADR.

03 · 7–9-cü həftələr

İnteqrasiya, təhlükəsizlik və əməliyyat

Mərhələnin məqsədi: Xarici və legacy sistemlərlə inteqrasiyanı, təhlükəsizlik/uyğunluq tələblərini və bulud xərcini arxitekturaya daxil etmək.

  1. Həftə 7

    İnteqrasiya arxitekturası: API-lər, mesajlaşma, legacy

    • API dizayn: versiyalaşma, geriyə uyğunluq, contract testing
    • Sinxron vs asinxron inteqrasiya və timeout/retry/circuit breaker
    • Legacy və bank tipli inteqrasiya: fayl mübadiləsi, SOAP, ISO 20022 mesajları, gecə batch-ləri
    • Anti-corruption layer və strangler yanaşması

    Laboratoriya: Bank core sistemi ilə fayl əsaslı reconciliation inteqrasiyasını dizayn edin: format, səhv idarəsi, təkrar göndərmə.

    Tapşırıq: Fərdi: inteqrasiya xəritəsi və bir legacy əlaqəsi üçün anti-corruption layer ADR-i.

  2. Həftə 8

    Təhlükəsizlik və uyğunluq arxitekturası

    • Threat modeling (STRIDE) və trust boundary-lər
    • AuthN/AuthZ arxitekturası: OIDC, servislər arası etibar, secret idarəsi
    • Data təsnifatı, şifrələmə, audit izi, retention
    • Uyğunluq çərçivələri: PCI DSS əsasları, şəxsi məlumatların qorunması

    Laboratoriya: Case üçün data flow diaqramı üzərində STRIDE seansı; ən azı 8 təhdid və onların azaldılması.

    Tapşırıq: Fərdi: threat model sənədi + kart/şəxsi data üçün sərhəd qərarı ADR-i.

  3. Həftə 9

    Bulud xərci və əməliyyat edilə bilənlik

    • SLI/SLO/error budget və onların arxitektura qərarlarına təsiri
    • Observability: log, metric, trace və alert keyfiyyəti
    • Multi-AZ/region, RTO/RPO və disaster recovery səviyyələri
    • FinOps: xərc modeli, unit economics, over-engineering xərci

    Laboratoriya: Üç deployment variantının (tək region, multi-AZ, multi-region) aylıq xərc və RTO/RPO müqayisəsi.

    Tapşırıq: Fərdi: SLO-lar, xərc modeli və tövsiyə olunan deployment variantı üçün ADR.

Yoxlama nöqtəsi: İnteqrasiya xəritəsi (API/mesaj/fayl kontraktları), threat model və SLO + xərc modeli olan yenilənmiş arxitektura paketi.

04 · 10–12-cü həftələr

Texniki liderlik və arxitektura müdafiəsi

Mərhələnin məqsədi: Arxitektura qərarlarını komanda və maraqlı tərəflər arasında RFC, roadmap və kommunikasiya ilə həyata keçirmək; yekun arxitekturanı müdafiə etmək.

  1. Həftə 10

    RFC prosesi, roadmap və texniki borc

    • RFC prosesi: kim yazır, kim baxır, necə qərar verilir
    • Texniki borcun təsnifatı və ödənişli/ödənişsiz borc fərqi
    • Arxitektura roadmap-ı: mərhələlər, asılılıqlar, risklər
    • Arxitektura review board-un riskləri və yüngül alternativlər

    Laboratoriya: Squad-lar case üçün RFC yazır, digər squad rəsmi reviewer rolunda yazılı rəy verir.

    Tapşırıq: Fərdi: 3 mərhələli arxitektura roadmap-ı və texniki borc reyestri (ən azı 6 maddə, prioritetlə).

  2. Həftə 11

    Maraqlı tərəflərlə kommunikasiya və mentorluq

    • Texniki qərarı biznes dilində izah etmək: risk, xərc, vaxt
    • Trade-off müzakirəsi və qeyri-müəyyənlik altında qərar
    • Mentorluq: senior mühəndisləri arxitektura düşüncəsinə yetişdirmək
    • Konflikt və razılaşma: 'razılaşıb dəstəkləmək' prinsipi

    Laboratoriya: Rol oyunu: CFO, risk meneceri və komanda lideri qarşısında 10 dəqiqəlik qərar təqdimatı, sonra geri bildirim.

    Tapşırıq: Fərdi: 1 səhifəlik icraçı xülasə (non-technical) və bir mentorluq sessiyası planı.

  3. Həftə 12

    Yekun layihə: arxitekturanın müdafiəsi

    • Yekun paketin yığılması və ardıcıllığı
    • Müdafiə strukturu: kontekst, əsas qərarlar, trade-off-lar, riskler
    • Çətin suallara cavab: 'əgər yük 10 dəfə artsa?', 'əgər provayder dəyişsə?'
    • Panel rəyi, retrospektiv və növbəti inkişaf planı

    Laboratoriya: Repetisiya müdafiəsi (squad daxilində), sonra instruktor və qonaq mühəndislərdən ibarət panel qarşısında 25 dəqiqəlik müdafiə.

    Tapşırıq: Fərdi: yekun arxitektura paketi (repozitoriya) və müdafiə sonrası 1 səhifəlik özünüdəyərləndirmə.

Yoxlama nöqtəsi: Yekun arxitektura paketi (tələblər, C4, ADR-lər, capacity, data, inteqrasiya, təhlükəsizlik, xərc, roadmap) və panel qarşısında müdafiə.

Maraq bildirin

Bu, müraciət və ya ödəniş öhdəliyi deyil. Proqram planlaşdırıldıqda və ya sizə uyğun format müzakirə olunduqda əlaqə saxlayırıq.

Sizinlə necə əlaqə saxlayaq?