Angular Projelerinde Temiz Mimari

Kurumsal Angular projelerinde temiz mimari, klasör adlarını değiştirmekten çok değişiklik maliyetini düşürme disiplinidir. Proje büyüdükçe component içine yazılan iş kuralları, doğrudan çağrılan HTTP servisleri ve tekrar eden validasyonlar teslimatı yavaşlatır. Bu yüzden feature-based yapı, domain fonksiyonları ve sade data-access katmanı birlikte düşünülmelidir.

Feature sınırları

Sipariş, kullanıcı, rapor veya teklif gibi ürün alanları kendi page, component, data-access ve domain dosyalarına sahip olmalıdır. Shared klasörü yalnızca gerçekten ortak UI parçaları için kullanılmalıdır. Böylece yeni bir geliştirici değişiklik yapacağı alanı daha hızlı bulur ve ekip içi çakışma azalır.

Component içinde iş kuralı tutmamak

Bir siparişin iptal edilebilir olup olmadığı veya bir kullanıcının butonu görüp görmeyeceği sadece görsel karar değildir. Aynı kural API isteğinde, liste filtresinde ve detay ekranında da kullanılabilir. Bu nedenle bu kararlar test edilebilir domain fonksiyonlarına taşınmalıdır.

Signals ve RxJS dengesi

Signals component içindeki senkron UI durumu için uygundur: seçili tab, açık modal, filtre ve hesaplanan değerler. RxJS ise HTTP akışı, debounce, retry, polling ve stream birleştirme gibi zaman bazlı işler için daha doğrudur. İkisini rakip görmek yerine sınırlarını net çizmek gerekir.

Test yaklaşımı

Domain fonksiyonları Angular bağımlılığı olmadan unit test ile doğrulanmalıdır. API servisleri HTTP mock testleriyle, kritik kullanıcı akışları ise az sayıda uçtan uca testle korunabilir. Her component için ağır test yazmak yerine riskli karar noktalarını kapsamak daha verimli sonuç verir.

Sonuç

Temiz mimari, projeyi akademik göstermek için değil, teslimatı sürdürülebilir kılmak için uygulanır. Feature sahipliği, sade component, test edilebilir domain kuralı ve kontrollü state yönetimi birleştiğinde Angular projesi büyüse bile okunabilir kalır.

Pratik uygulama notu

Bu yaklaşımı yeni bir projeye taşırken önce klasör yapısını değil, değişiklik nedenlerini çıkarırım. En sık değişen ekranlar, ortak validasyonlar ve API sınırları belirlendikten sonra feature ayrımı daha doğru yapılır. Mevcut projede ise büyük taşıma yerine önce bir feature seçip component içindeki iş kurallarını domain fonksiyonlarına almak daha düşük risklidir.