Question 1

Flutter layihəsinin arxitekturasını necə qurursan?

Accepted Answer

İki qatdan başla: UI (widget + ekran vəziyyətini saxlayan obyekt) və data (repository + service). Qaydanı aydın de: UI heç vaxt birbaşa HTTP çağırmır — repository-dən domen obyekti alır. Asılılıq istiqaməti həmişə UI → repository → service, tərsinə heç vaxt. Qovluqları feature üzrə bölürəm, tip üzrə yox: 40 ekranlı tətbiqdə bir dəyişikliyin dörd uzaq qovluğa toxunması real ağrıdır. Sonda nə vaxt daha çox qat lazım olduğunu de: mürəkkəb biznes qaydaları varsa use case qatı əlavə edirəm, sadə CRUD-da isə bu, lazımsız boilerplate olardı.

Question 2

Repository pattern-i nə üçün lazımdır?

Accepted Answer

Üç konkret səbəb. (1) Test — repository interfeysdirsə, testdə saxta implementasiya verib ekranı şəbəkəsiz, dəqiq və sürətli test etmək olur; bu, ən böyük praktik fayda. (2) Mənbənin dəyişməsi — bu gün REST, sabah GraphQL və ya offline cache; UI kodu toxunulmadan qalır. (3) Cache və birləşdirmə məntiqi bir yerdə — "əvvəl lokal bazadan oxu, sonra şəbəkədən yenilə" qaydası repository-də yaşayır, hər ekranda təkrarlanmır. Əlavə et ki, bu pattern hər layihədə lazım deyil: bir-iki ekranlı prototipdə birbaşa API çağırışı kifayətdir və artıq abstraksiya xərcdir.

Question 3

Qovluqları feature üzrə, yoxsa tip üzrə bölürsən?

Accepted Answer

Feature üzrə. Tip üzrə bölgü (lib/models, lib/screens, lib/services) demo layihədə səliqəli görünür, amma böyüdükcə problem yaradır: bir feature üzərində işləyəndə dörd ayrı qovluq arasında gəzirsən, komandada eyni qovluqlarda münaqişə çoxalır, feature-i silmək və ya ayrıca paketə çıxarmaq çətinləşir. Feature üzrə bölgüdə isə features/orders/ daxilində data, domain, presentation alt qovluqları olur — dəyişiklik bir yerdə cəmlənir. Paylaşılan şeylər üçün core/ qovluğu saxlayıram. Bu, texniki deyil, saxlanma qərarıdır və layihənin ölçüsündən asılıdır.

Question 4

Clean Architecture-i Flutter-də tətbiq etmək lazımdırmı?

Accepted Answer

Balanslı cavab gözlənilir. Clean Architecture-in dəyərli ideyası asılılıq istiqamətidir: daxili qatlar xarici qatları tanımır. Bu, Flutter-də də faydalıdır. Amma tam kanonik forma — entity, use case, repository, data source, hər biri üçün ayrı model və mapper — kiçik və orta tətbiqdə çox vaxt xərcdən artıq fayda vermir: sadə bir sahə əlavə etmək üçün beş faylı dəyişmək lazım gəlir. Mənim yanaşmam: rəsmi Flutter bələdçisindəki iki qatla başlamaq və ehtiyac yarananda qat əlavə etmək. Arxitekturanı əvvəlcədən "hər ehtimala qarşı" qurmaq ən çox rast gəlinən həddindən artıq mühəndislik halıdır.

Qat	Məsuliyyəti	Nəyi BİLMİR
Widget	Göstərmək, hadisə ötürmək	API-nin JSON formatını, HTTP status kodlarını
ViewModel / Bloc	Ekran vəziyyətini idarə etmək	Şəbəkə kitabxanasını (dio/http)
Repository	Data mənbəyini seçmək, cache məntiqi	Widget-ləri və `BuildContext`-i
Service	Bir mənbə ilə danışmaq (API, DB)	Biznes qaydalarını

Layihə arxitekturası və qatlar

📚 Mənbələr və sənədlər