Over-engineering sərhədi: nə vaxt sadələşdirmək

Bu branch boyu qatların qazancını göstərdik. Bu mövzu əks tərəfdən — qiymətindən danışır, çünki hər abstraksiyanın ödənilməli olan haqqı var.

Rəsmi Flutter tövsiyələri özləri bu balansı qurur: bəndlərin bir hissəsi ən yüksək prioritetdədir (data/UI ayrılığı, repository, MVVM, DI, immutable modellər, fake-lərlə test), digər hissəsi isə şərtli (domain qatı, ayrı API/domain modelləri, konkret state management seçimi).

Şərtli bəndlərin şərtləri konkretdir:

• Domain qatı (use-case-lər) — yalnız view model-ləri sıxışdıran mürəkkəb məntiq olduqda. Bələdçi əksər tətbiqlər üçün onu artıq yük sayır.
• Ayrı API və domain modelləri — böyük tətbiqlərdə tövsiyə olunur, kiçikdə əlavə söz-söhbət yaradır.

Bundan çıxan praktik nəticə: "tam dəst" arxitektura hər layihə üçün düzgün cavab deyil. Kiçik layihədə minimum dəst (service + repository + notifier) rəsmi tövsiyələrin ən yüksək prioritetli hissəsini tam ödəyir.

Over-engineering-in əlamətləri. Bunlar konkret və müşahidə ediləndir:

• Bir sətirlik siniflər. class GetProductsUseCase { call() => _repo.fetchActive(); } — məntiq yoxdur, yalnız ötürmə.
• Yalnız bir istifadəçisi olan abstraksiya, testdə də əvəz olunmayan. İnterfeys var, lakin implements edən bir sinif və o da heç vaxt dəyişməyəcək.
• Naviqasiya dərinliyi. Bir baqı izləmək üçün 6 fayl açmaq lazımdır: widget → notifier → use-case → repository → mapper → service.
• Boş qovluqlar. usecases/, entities/, datasources/ — şablondan gəlib, lakin heç vaxt istifadə olunmayıb.
• Yalnız mock quraşdırmasından ibarət testlər. Test 20 sətir when(...) və 1 sətir expect — belə test davranışı yoxlamır.
• Öz "framework"ün. Bir feature üçün yazılmış generic bazalar: BaseRepository<T>, BaseNotifier<S, E>.

Əks tərəf: under-engineering əlamətləri. Balansı görmək üçün onları da bilmək lazımdır:

• Testdə HTTP-ni ya da JSON-u mock etmək lazım gəlir.
• Eyni hesablama 3+ yerdə təkrarlanır.
• Backend bir sahəni dəyişdikdə 5+ fayl sınır.
• build metodu 200 sətirdir.
• İstifadəçi SocketException mesajını görür.

Yoxlama sualı. Hər abstraksiya üçün: "bunu silsəm, nə pisləşəcək?" Cavab konkret olmalıdır ("testdə şəbəkəni əvəz edə bilməyəcəyəm", "ikinci ekran kodu kopyalayacaq"). Cavab "clean architecture-a uyğun olmayacaq"dırsa — abstraksiya öz səbəbini itirmişdir.