Bir uygulama büyüdükçe en önemli soru şu olur: "Hangi kod nereye yazılır?" Mimari, bu sorunun ekipçe paylaşılan cevabıdır. Katmanlı mimari ve onun modern yorumu Clean Architecture, yıllardır kurumsal yazılımların en yaygın düzenleme biçimidir.
Klasik katmanlı mimari
Uygulama üç temel katmana ayrılır:
- Sunum katmanı: Web sayfaları, API uçları, masaüstü ekranları
- İş katmanı: Kurallar, hesaplamalar, iş akışları
- Veri katmanı: Veritabanı erişimi, dış servis çağrıları
Her katman yalnızca altındakiyle konuşur. Basit ve anlaşılırdır; ancak iş katmanının veri katmanına bağımlı olması, iş kurallarını veritabanı ayrıntılarına bağlar.
Clean Architecture: bağımlılık kuralı
Clean Architecture (ve benzerleri Onion, Hexagonal) şu kuralı koyar: bağımlılıklar her zaman içe doğrudur. Merkezde iş kuralları vardır ve hiçbir dış ayrıntıyı bilmez.
| Katman | İçerik | Neye bağımlı? |
|---|---|---|
| Domain | Varlıklar, iş kuralları | Hiçbir şeye |
| Application | Kullanım senaryoları, arayüzler | Domain |
| Infrastructure | Veritabanı, e-posta, dosya, dış API | Application, Domain |
| Presentation | API, web, masaüstü arayüz | Application |
Veritabanı veya e-posta sağlayıcısı değiştiğinde yalnızca Infrastructure katmanı etkilenir. Bu, SOLID'in bağımlılıkların tersine çevrilmesi ilkesinin mimari ölçekteki uygulamasıdır.
.NET'te örnek yapı
src/
Siparis.Domain/ // Siparis, Musteri, Para gibi tipler ve kurallar
Siparis.Application/ // SiparisOlustur, ISiparisDeposu
Siparis.Infrastructure/ // EF Core, SMTP, kargo API istemcisi
Siparis.Api/ // Minimal API uçları
tests/
Siparis.Domain.Tests/
Siparis.Application.Tests/Artıları
- İş kuralları veritabanı ve arayüzden bağımsız test edilebilir.
- Teknoloji değişikliklerinin etkisi sınırlı kalır.
- Büyük ekiplerde sorumluluk sınırları nettir.
Eksileri
- Küçük projelerde gereksiz dosya ve katman kalabalığı oluşur.
- Basit bir alan eklemek için dört projeye dokunmak gerekebilir.
- Yanlış uygulandığında her katmanda birbirinin kopyası olan sınıflar çoğalır.
Alternatif: Dikey dilimler (vertical slice)
Kodu teknik katmanlara göre değil, özelliklere göre gruplar: "SiparisOlustur" klasöründe o özelliğin uç noktası, doğrulaması, iş mantığı ve veri erişimi bir aradadır. Değişiklikler tek bir yere toplanır ve küçük-orta projelerde çok verimlidir. Pek çok ekip iki yaklaşımı birleştirir: domain katmanı ayrı, uygulama tarafı özellik bazlı.
Hangisini seçmeli?
- Birkaç ekranlık bir iç araç: basit katmanlar veya tek proje yeterli
- Uzun ömürlü, karmaşık iş kuralları olan bir sistem: Clean Architecture
- Hızlı gelişen, özellik odaklı bir ürün: dikey dilimler
Mimari, projenin gerçek karmaşıklığıyla orantılı olmalıdır. Uygulamanın tek parça mı yoksa servislerle mi kurulacağı ayrı bir karardır: monolit mi mikroservis mi.
Sık sorulan sorular
Repository katmanı şart mı?
Değil. EF Core'un DbContext'i zaten bir repository ve unit of work gibi davranır; ek katman yalnızca somut bir ihtiyaç varsa eklenmelidir.
Masaüstü uygulamalarda da geçerli mi?
Evet. WPF'te MVVM sunum katmanını düzenler; iş ve veri katmanları aynı ilkelerle ayrılabilir.
Sonuç
İyi bir mimari, kodun nereye yazılacağını tartışmaya gerek bırakmaz. Bağımlılıkları içe doğru tutmak ve karmaşıklığı ihtiyaca göre ölçeklemek, uzun ömürlü uygulamaların sırrıdır.
