Katmanlı Mimari ve S.O.L.I.D Prensiplerine Giriş

Yazılım projelerinde sürdürülebilirlik, test edilebilirlik ve esneklik hedeflendiğinde iki kavram sıkça ön plana çıkar: katmanlı (N-tier) mimari ile S.O.L.I.D tasarım ilkeleri. Katmanlı mimari, uygulamayı sorumluluklara göre ayırarak daha kolay yönetilebilir hâle getirir; S.O.L.I.D ise sınıf ve modül düzeyinde iyi tasarım kurallarını tanımlar. Bu makalede hem kavramsal açıklama hem de pratik uygulama adımları bulacaksınız.

Katmanlı (N-tier) Mimari Nedir?

Katmanlı mimari, yazılım uygulamalarını işlevsel katmanlara bölerek her katmanın tek bir sorumluluğu üstlenmesini sağlar. Resmi kaynaklarda N-katmanlı yaklaşım, kullanıcı arayüzü, iş mantığı ve veri erişimi gibi ayrımları netleştirerek ölçeklenebilirlik ve bakım kolaylığı sunduğu şeklinde tanımlanır: Microsoft Learn: N katmanlı Mimari.

Tipik Katmanlar ve Sorumlulukları

• Sunum Katmanı (Presentation/UI): Kullanıcı etkileşimi, yönlendirme, input/validation.
• Uygulama/Servis Katmanı (Application/Service): İş akışlarını koordine eder; controller veya service sınıfları burada yer alır.
• Domain/İş Katmanı (Domain/Business): İş kuralları ve domain modelleri.
• Veri Erişim Katmanı (Data Access): Repository ve veri kaynaklarına erişim kodları.
• Altyapı/Entegrasyon (Infrastructure): Dış sistemlerle iletişim, logging, caching gibi teknik konular.

S.O.L.I.D Prensipleri — Kısa Özeti

S.O.L.I.D, beş temel prensibi kapsar: Tek Sorumluluk (SRP), Açık/Kapalı (OCP), Liskov Yerine Geçme (LSP), Arayüz Ayırma (ISP) ve Bağımlılıkların Tersine Çevrilmesi (DIP). Bu kurallar, sınıf ve modül seviyesinde değişiklik maliyetini azaltmayı hedefler. Temel tanımlar için referans: Ufuk.in — SOLID nedir?.

Her Prensibin Katmanlı Mimaride Uygulama Örneği

• SRP (Single Responsibility): Bir OrderService yalnızca sipariş iş kurallarını uygular; loglama veya faturalama ayrı sorumluluklara ayrılır.
• OCP (Open/Closed): Yeni ödeme sağlayıcısı eklerken mevcut sınıfları değiştirmeden yeni bir IPaymentProvider implementasyonu eklenir.
• LSP (Liskov): Bir FileStorage ve CloudStorage sınıfı, ortak bir IStorage arayüzünü tutarlı şekilde uygulamalıdır; beklenmeyen davranışlar veya istisnalar bozulmamalıdır.
• ISP (Interface Segregation): Veri erişim arayüzleri, sadece gerekli operasyonları içerecek şekilde parçalanmalı (ör. IReadOrder, IWriteOrder).
• DIP (Dependency Inversion): Üst seviye servisler somut veri erişimine bağlı olmamalı; her iki taraf da soyutlamalara (interface/abstract) bağlı olmalıdır.

Katmanlı Mimari ile S.O.L.I.D Birlikte Nasıl Çalışır?

Katmanlı mimari, farklı sorumlulukları fiziksel veya mantıksal olarak ayırırken S.O.L.I.D prensipleri bu katman içi ve katmanlar arası bağımlılıkları düzenler. Örneğin veri erişim katmanında Repository tasarım deseni kullanılırken arayüzler aracılığıyla DIP uygulanır; servis katmanında açık/kapalı ilkesini korumak için strateji veya fabrika desenleri tercih edilebilir.

Pratik Adımlar: Varolan Bir Uygulamayı İyileştirme

Aşağıdaki adımlar, mevcut bir monolitik uygulamayı daha modüler ve S.O.L.I.D uyumlu hâle getirmek için kullanılabilir:

1. Sorumluluk analizi yapın: Her sınıfın neden değiştiğini not edin; birden fazla nedenle değişen sınıfları tespit edin.
2. Sınıfları ve metodları ayırın: SRP ihlali olan sınıfları alt sınıflara veya yardımcı sınıflara bölün.
3. Arayüzler oluşturun: Veri erişimi ve dış servislerle iletişim için soyutlamalar ekleyin (DIP).
4. Bağımlılık enjeksiyonu uygulayın: Somut sınıf new'lemelerini constructor injection ile değiştirin.
5. Test yazın: Ayrıştırılmış birimlerin davranışını doğrulayan birim testleri ekleyin.
6. Tasarım desenleriyle genişletin: Strategy, Adapter veya Factory ile OCP'yi destekleyin.
7. Katman sınırlarını kontrol edin: UI'nın doğrudan veri tabanı çağrısı yapmadığından emin olun.

Kontrol Listesi (Deployment Öncesi)

• Her sınıfın tek bir sorumluluğu var mı?
• Yeni özellik eklerken mevcut kod değiştiriliyor mu?
• Arayüzler gereksiz büyük mü, yoksa parçalanmış mı?
• Üst seviye modüller somut alt seviye detaylara bağımlı mı?
• Yeterli birim testi mevcut mu?

Yaygın Anti-patternler ve Nasıl Kaçınılır

• God Object: Çok fazla sorumluluk taşıyan tek bir sınıf. Çözüm: SRP ile ayırma.
• Fazla kompleks arayüzler: Implementasyonları gereksiz yere zorlayan geniş arayüzler. Çözüm: ISP uygulayın.
• Sıkı Bağımlılıklar: Somut sınıflara doğrudan new'leme. Çözüm: DIP + injector kullanın.
• Anemic Domain Model: Domain modelinin davranışsız olması. Çözüm: Davranışı domain katmanına taşıyın.

Örnek Senaryo: Basit E-Ticaret Sipariş Akışı (Sözlü Model)

Senaryo - sipariş oluşturma: Kullanıcı UI üzerinden sipariş verir. UI, OrderController'a istek yollar; controller bir OrderService çağırır. OrderService iş kurallarını uygular, ödeme için IPaymentProvider arayüzünü kullanır ve siparişi IOrderRepository aracılığıyla kaydeder. Her bir bileşen tek bir sorumluluğa sahiptir, IPaymentProvider yeni ödeme sağlayıcıları eklemeye izin verir (OCP), ve servisler arayüzlere bağımlı olacak şekilde tasarlanmıştır (DIP).

Tasarım Deseni Örnekleri ve Nerede Kullanılır

• Repository Pattern: Veri erişim mantığını soyutlamak için veri katmanında kullanılır.
• Factory/Abstract Factory: Domain veya servis katmanında nesne yaratımını merkezi hale getirir, OCP ile uyumludur.
• Adapter: Harici API'leri uygulamanın beklediği arayüze uydurmak için altyapıda tercih edilir.
• Strategy: Farklı algoritma veya ödeme yöntemleri arasında değişimi kolaylaştırır.

Kaynaklar ve İleri Okuma

Daha derin teknik açıklamalar ve resmi tanımlar için aşağıdaki kaynaklara başvurabilirsiniz:

• N katmanlı Mimari Stili — Microsoft Learn (N-tier açıklamaları ve uygulama örnekleri).
• SOLID Prensipleri — Ufuk.in (prensiplerin tanımları ve örnekler).
• Yazılım Tasarımı ve Mimari Prensipleri — Emre Karademir (uygulama ve iyi uygulama önerileri).

Sonuç

Katmanlı mimari ve S.O.L.I.D prensipleri birlikte ele alındığında projelerin bakım kolaylığı, test edilebilirlik ve genişletilebilirliği önemli ölçüde iyileşir. Bu makaledeki pratik adımlar ve kontrol listesi, mevcut uygulamanızı parçalayıp sorumlulukları netleştirerek ilerlemenize yardımcı olacak şekilde tasarlandı. Daha ileri uygulamalar için yukarıdaki kaynakları inceleyin ve küçük adımlarla refaktoring yapmayı tercih edin.

Not: Makaledeki teknik öneriler genel iyi uygulamalara dayanır ve proje bağlamına göre uyarlanmalıdır. Detaylı mimari kararlar alınırken sistem gereksinimleri, performans kısıtları ve ekip yetkinlikleri göz önünde bulundurulmalıdır.