Clean Architecture, yazılım dünyasında “düzenli ve sürdürülebilir yapı” denince akla gelen en güçlü yaklaşımlardan biridir. Ancak pratikte ekipler çoğu zaman iki uçtan birine kayar: Ya teoriyi birebir uygular ve aşırı katman çıkarır, ya da “zaten zaman yok” deyip tamamen bırakır. Oysa gerçek projelerde doğru olan şey, Clean Architecture’ı ihtiyaç kadar uygulamak ve ekibe hız kazandıracak şekilde sadeleştirmektir.
Bu yazıda Clean Architecture’ın temel fikirlerini koruyarak, gerçek projelerde nasıl uygulanacağını net örneklerle ele alıyoruz.
🧭 Clean Architecture Ne Çözer?
Clean Architecture, kodu “katmanlara” ayırırken asıl hedefi şudur:
İş kuralları (core) dış dünya bağımlılıklarından bağımsız kalsın.
Böylece:
- test yazmak kolaylaşır,
- kodun ömrü uzar,
- teknoloji değişse bile iş kuralları ayakta kalır.
Ancak bu hedefi yakalamak için her projede aynı yoğunlukta katman şart değildir.
📌 Teoride Katmanlar Nasıl Konuşur?
Klasik Clean Architecture akışında katmanlar şu sırayı izler:
- Entities (Domain): İşin çekirdeği, kurallar
- Use Cases (Application): İş akışları / senaryolar
- Interface Adapters: Controller, Presenter, Mapper
- Frameworks & Drivers: DB, HTTP, UI, dış servisler
En kritik kural: Bağımlılıklar içe doğru akar.
Yani dış katmanlar içe bağımlı olur; çekirdek dışarıdan habersiz yaşar.
🧩 Pratikte Ekiplerin Takıldığı Yerler
Gerçek projelerde en sık yaşanan problemler şunlardır:
1) Aşırı katman üretmek
Ekip, her küçük işlem için ayrı use-case, ayrı interface, ayrı mapper yazınca proje “heavy” hale gelir. Bu durum hız kaybettirir.
2) Her şeyi “domain”e taşımak
Bazı ekipler, config, validasyon, hatta DTO’ları bile domain’e sıkıştırır. Sonuçta domain kirlenir ve çekirdek değerini kaybeder.
3) Sınırları yanlış çizmek
Clean Architecture, klasör düzeninden ibaret değildir. Asıl mesele bağımlılık yönünü korumaktır. Yani doğru abstractions kurmadan sadece klasör bölmek işe yaramaz.
✅ Gerçek Projelerde Uygulanabilir Yol Haritası
1) Önce Domain’i küçük tut
Domain katmanına yalnızca gerçekten iş kuralı olan şeyleri koy:
- hesaplama
- kural doğrulama
- karar mekanizması
Eğer bir şey “framework’e” veya “DB’ye” bağlıysa domain’de durmamalı.
2) Use Case’leri “iş aksiyonları” olarak yaz
Use case, kullanıcı niyetini temsil etsin:
- CreateOrder
- PayOrder
- AssignConsultant
- GenerateInvoice
Bu sayede hem test kolaylaşır hem de ekip, “işi” okuyarak sistemi anlar.
3) Repository interface’i içeride tanımla
Domain/Application katmanında interface’i tut, implementasyonu dış katmanda yaz.
OrderRepositoryinterface: içerideMongoOrderRepository: dışarıda
Böylece veri kaynağı değişse bile core etkilenmez.
4) DTO ve Validation’ı doğru yere koy
- HTTP request DTO’ları: dış katman
- Use case input modeli: application katmanı
- Domain doğrulamaları: domain katmanı
Bu ayrım, domain’i temiz tutar.
5) “Sade Clean Architecture” ile başla
Her projede tam Clean Architecture gerekmez. Bunun yerine şu pratik modeli kullan:
- domain
- application
- infrastructure
- presentation (api/web)
Bu yapı, çoğu gerçek projede hem yeterli hem de hızlıdır.
🏗️ Örnek Klasör Yapısı (Gerçekçi)
src/domain- entities
- value-objects
- services (domain services)
src/application- use-cases
- ports (interfaces)
- dtos (use-case input/output)
src/infrastructure- db (mongo, postgres)
- repositories (implementations)
- integrations (payment, mail)
src/presentation- controllers
- routes
- middlewares
Bu yapıda ekip, nerede ne yazacağını net görür. Üstelik framework bağımlılıkları dışarıda kalır.
⚖️ Teori vs Pratik: Dengeli Karar Nasıl Verilir?
Pratikte şu kural çok işe yarar:
- İş kuralları karmaşıksa, Clean Architecture yatırımını artır.
- Proje küçük ve kısa ömürlüyse, yalın bir yapı kur ve abartma.
- Ekip kalabalıksa, katmanlar düzen sağlar.
- Ekip küçükse, aşırı katman hız keser.
Yani Clean Architecture’ı “şablon” değil “araç” gibi düşün.
🛠️ mr.tek Perspektifi
mr.tek olarak Clean Architecture’ı dogma gibi uygulamıyoruz. Biz önce projenin ölçeğini, ekip yapısını ve büyüme hedefini inceliyoruz. Ardından “sade Clean Architecture” ile başlıyoruz. Proje büyüdükçe katmanları bilinçli şekilde genişletiyoruz. Böylece hem hız kaybetmiyoruz hem de uzun vadede bakımı kolay bir yapı koruyoruz.
✅ Sonuç
Clean Architecture, gerçek projelerde doğru uygulanırsa ciddi bir avantaj sağlar. Ancak her katmanı birebir kopyalamak yerine, ihtiyaca göre sadeleştirmek gerekir. Domain’i temiz tut, use case’leri iş aksiyonu gibi yaz, bağımlılık yönünü koru. Böylece teoriye saygı gösterirken pratikte de hızlı kalırsın.
Etiketler
#cleanarchitecture, #yazilimmimarisi, #backend, #domain, #usecase, #solid, #mikroservisler, #nodejs, #mrtek
