Yazılım mimarisi nedir, neden önemlidir?

Yazılım mimarisi, bir uygulamanın “hangi parçalardan oluştuğu”, bu parçaların “nasıl iletişim kurduğu” ve bu yapı üzerinden “nasıl değiştirileceği/ölçekleneceği” gibi kararların bütünüdür. Kod yazmaya başlamadan önce (ve yazım sürecinde) mimariyi düşünmek, özellikle şu hedeflere hizmet eder:

• Sürdürülebilirlik: Yeni özellik eklemek, hataları izlemek ve test etmek kolaylaşır.
• Ölçeklenebilirlik: Trafik ve veri arttığında uygulamayı büyütmek için daha net seçenekler oluşur.
• Güvenilirlik: Arızaların etkisini sınırlamak ve geri dönüş (rollback) yapmak daha kontrollü hale gelir.
• Ekip çalışması: Sorumlulukların sınırları netleştiğinde ekipler paralel çalışabilir.

Bu yazıda iki yaygın yaklaşımı karşılaştıracağız: katmanlı (layered / n-tier) mimari ve mikroservis mimarisi. İkisi de “doğru/yanlış” değil; bağlama göre anlamlı tercihlerdir.

Katmanlı (n-tier / layered) mimari: Temel fikir

Katmanlı mimari, uygulamayı yatay katmanlara ayırır. Pratikte en sık görülen ayrım; sunum (presentation), iş mantığı (business logic) ve veri erişimi (data access) katmanlarıdır. Microsoft’un mimari stiller rehberi, katmanlı yaklaşımı ve kullanım koşullarını özetler (Microsoft Azure Architecture Center).

Tipik katmanlar (örnek)

• Presentation (UI/API): HTTP isteklerini alır, doğrulama ve yanıt formatlama yapar.
• Application/Service layer: Use-case’leri yürütür (ör. “sipariş oluştur”).
• Domain (iş kuralları): Kuralları ve temel modeli (entity/value object) taşır.
• Data Access: Veritabanı sorguları, repository/ORM entegrasyonu.

Katmanlar arası bağımlılıklar genellikle “üst katman alt katmanı çağırır” şeklindedir. Amaç, örneğin UI’nin doğrudan SQL yazmaması; iş kurallarının da UI detaylarından etkilenmemesidir.

Ne zaman iyi çalışır?

• Tek uygulama olarak yayınlanan (tek deployable) sistemlerde
• Ekip küçük/orta ölçekliyken
• Veri tutarlılığı gereksinimleri yüksekken (tek veritabanında transaction yönetimi daha basittir)
• Ürünün erken aşamasında, gereksinimler hızla değişiyorken

Avantajlar ve sınırlamalar

• Avantaj: Kavraması ve uygulaması görece kolay; yeni ekip üyeleri hızlı adapte olur.
• Avantaj: Tek uygulama içinde test, debug ve transaction yönetimi daha basit olabilir.
• Sınırlama: Zamanla “tek parça” büyür; her değişiklik tüm uygulamanın yeniden dağıtımını gerektirebilir.
• Sınırlama: Bağımsız ölçekleme zordur; bir modül yoğun trafik alınca tüm uygulamayı büyütmek gerekebilir.

Mini örnek: “Sipariş oluştur” akışı (katmanlı)

Bir e-ticaret uygulamasında “Sipariş Oluştur” use-case’ini katmanlı mimaride şöyle düşünebilirsiniz:

1. API Controller istek alır: kullanıcı, sepet, adres bilgileri.
2. OrderService iş akışını yönetir: stok kontrolü, fiyat hesaplama, ödeme başlatma.
3. Domain kuralları uygular: indirim kuralı, kargo kuralı, sipariş durum geçişleri.
4. OrderRepository veritabanına yazar; gerekiyorsa tek transaction içinde tamamlanır.

Bu yaklaşım, özellikle tek veritabanında ACID transaction ihtiyacı olan işlerde hızlı ve nettir.

Mikroservis mimarisi: Temel fikir

Mikroservis mimarisi, sistemi iş yeteneklerine göre daha küçük, otonom servisler olarak tasarlar. AWS, mikroservisleri bağımsız dağıtılabilen ve belirli bir iş fonksiyonuna odaklanan servisler olarak tanımlar (AWS Microservices). Pek çok pratik rehberde, servislerin kendi verilerini sahiplenmesi (servis başına veri depolama yaklaşımı) özellikle vurgulanır (microservices.io).

Mikroservislerde “doğru bölme” ne demek?

Mikroservis, “küçük olsun” diye değil, anlamlı sınırlar üzerinden ayrıştırıldığında işe yarar. Pratikte iki güçlü ipucu:

• İş yeteneği odaklı bölme: “Katalog”, “Sipariş”, “Ödeme”, “Kargo” gibi (genel tanım için AWS).
• Bounded context yaklaşımı: Aynı terimin farklı anlamları olabileceği alanları ayırmak (ör. “müşteri” kavramı pazarlama ve faturalamada farklı kurallara sahip olabilir). Bu tür sınırlandırma, mikroservis pratiklerinde desenler ve geçiş stratejileriyle birlikte sık anılır (microservices.io).

Avantajlar ve sınırlamalar

• Avantaj: Her servis bağımsız dağıtılabildiği için sürümleme ve yayın döngüsü hızlanabilir (organizasyon ve otomasyon olgunluğuna bağlıdır) (AWS; pratik perspektif için Sam Newman).
• Avantaj: Trafiği yüksek servisi ayrı ölçekleyebilirsiniz (ör. sadece Katalog servisini büyütmek) (AWS).
• Avantaj: Takımlar arası sahiplik netleşebilir; servisler ekip sınırlarıyla hizalanabilir (organizasyonel boyut için Sam Newman).
• Sınırlama: Dağıtık sistem maliyetleri artar: ağ gecikmesi, hata senaryoları, gözlemlenebilirlik ihtiyacı, daha karmaşık dağıtım (genel zorluk çerçevesi: CNCF Annual Cloud Native Survey 2025).
• Sınırlama: Veri tutarlılığı daha zor bir problem haline gelir; tek transaction yerine koreografi/orkestrasyon gibi yaklaşımlar gerekebilir (Gilbert & Lynch, 2002).

Mini örnek: 2 servis + API gateway (mikroservis)

Benzer e-ticaret örneğini mikroservislerle düşünelim:

• Catalog Service: Ürünler, fiyatlar, stok görüntüleme (kendi veritabanı).
• Order Service: Sepetten sipariş yaratma, sipariş durumu, ödeme sürecini başlatma (kendi veritabanı).
• API Gateway (opsiyonel): İstemciler için tek giriş noktası; rotalama ve kimlik doğrulama gibi çapraz kesen konuları toplamak için sık kullanılan bir yaklaşımdır (genel mikroservis yaklaşımı: AWS; desen kataloğu: microservices.io).

Burada kritik fark şudur: Order Service siparişi yazarken Catalog Service veritabanına doğrudan bağlanmaz. Gerekirse Catalog Service’den API ile veri alır veya “ürün fiyatı güncellendi” gibi bir olay (event) üzerinden kopyalanmış veriyi (read model) tutar. Bu yaklaşım mikroservislerde veri sahipliği (ownership) ve servisler arası entegrasyon pratikleriyle uyumludur (microservices.io).

Mikroservisler vs Monolit: Karar Çerçevesi

“Mikroservis mi, monolit mi?” sorusunu tek cümleyle yanıtlamak risklidir; çünkü performans, maliyet ve ekip hızı gibi çıktılar uygulamaya göre ciddi değişkenlik gösterir. Bu yüzden karar için kriter tablosu kullanmak daha sağlıklıdır. Ayrıca birçok uzman, özellikle ürünün erken aşamalarında monolith-first (başta modüler bir monolit) yaklaşımının riski düşürdüğünü savunur (Martin Fowler; pratik geçiş perspektifi için Sam Newman).

Hızlı karar kontrol listesi

• Şimdilik katmanlı/modüler monolit seçin eğer: tek ekip/tek ürün, hızlı değişen gereksinimler, tek veritabanında güçlü tutarlılık ihtiyacı varsa (Microsoft; Fowler).
• Mikroservisleri düşünün eğer: birden fazla ekip bağımsız yayın yapmak istiyor, belirli alanlar çok farklı ölçekleniyor, operasyon/otomasyon yatırımı yapmaya hazırsanız (AWS; Newman).
• “Önce sınır, sonra dağıtım”: Monolit içinde modülleri/bounded context’leri netleştirmek, ileride servisleşmeyi kolaylaştırır (microservices.io).

Pratik öneri: Eğer henüz ürün-pazar uyumu arıyorsanız, önce iyi ayrıştırılmış bir modüler monolit kurup mimari sınırları temiz tutmak, sonra gerçekten ihtiyaç doğduğunda servis çıkarmak çoğu ekip için daha düşük riskli bir yoldur (Martin Fowler).

Dağıtık veri ve CAP: Mikroservislerde “zor” olan kısım

Mikroservislere geçince en çok zorlayan alanlardan biri veri tutarlılığıdır. Dağıtık sistemlerde meşhur CAP teoremi, ağ bölünmesi (partition) durumunda aynı anda hem güçlü tutarlılık hem de tam erişilebilirlik garantisi verilemeyeceğini söyler. CAP’in formel temeli için Gilbert & Lynch’in çalışması referans gösterilir (Gilbert & Lynch, 2002).

Bu, uygulama tasarımını nasıl etkiler?

• Senaryo: Sipariş servisi siparişi “alındı” olarak işaretledi ama ödeme servisi geç yanıt veriyor.
• Soru: Kullanıcıya ne göstereceksiniz? “Ödeme bekleniyor” gibi bir ara durum mu tanımlayacaksınız?
• Sonuç: Çok-servisli iş akışlarında, çoğu ekip eventual consistency (zamanla tutarlılık) ve durum makineleri (state machine) gibi yaklaşımlara ihtiyaç duyar (desen kataloğu: microservices.io).

Bu noktada pratikte sık anılan desenlerden biri Saga yaklaşımıdır: Çok adımlı bir iş akışını, her adımın kendi “tamamlandı” bilgisini üretmesi ve gerektiğinde “telafi edici işlem” (compensating action) çalıştırmasıyla yönetirsiniz (örnek desenler: microservices.io).

Monolitten mikroservise kademeli geçiş: Strangler yaklaşımı

Çoğu gerçek sistem, “bir hafta sonu” mikroservise dönüşmez. Kademeli bir yol izlemek daha güvenlidir. Pratikte en bilinen stratejilerden biri Strangler pattern’dir: Yeni fonksiyonları yeni servislere yazıp, eski monolitin ilgili parçalarını zamanla devre dışı bırakırsınız (göç stratejileri: microservices.io; organizasyonel/pratik perspektif: Sam Newman).

Adım adım uygulanabilir plan

1. Önce sınırları netleştirin: Monolit içinde modülleri ayırın (paketleme, bağımlılık yönü, domain sınırları).
2. İlk aday servisi seçin: En riskli çekirdek yerine, daha izole bir alan seçin (ör. bildirim/notification, raporlama).
3. Arayüz sözleşmesini belirleyin: API’ler ve olaylar (events) için sözleşme tasarlayın; versiyonlamayı düşünün.
4. Veriyi ayırma stratejisi seçin: Yeni servis kendi verisini yönetmeli (servis başına veri sahipliği ilkesi: microservices.io).
5. Yönlendirme katmanı ekleyin: Trafiği yeni servise kademeli aktaracak bir yönlendirme/routing yaklaşımı planlayın (Strangler yaklaşımı: microservices.io).
6. Gözlemlenebilirliği en baştan ekleyin: İstek kimliği (correlation id), log/metric/tracing olmadan servis sayısı arttıkça sorun çözmek zorlaşır (operasyonel ihtiyaçların görünür hale gelmesi: CNCF 2025).
7. Kademeli devreye alma: Küçük adımlarla ilerleyip geri dönüş planı (rollback) ve risk kontrolü tasarlayın (genel mikroservis pratikleri: Sam Newman).

Not: Geçiş boyunca “tek veritabanını paylaşan mikroservisler” kısa vadede kolay görünse de, servis bağımsızlığını zayıflatır. Bu nedenle geçiş planında veri sahipliğini (ownership) netleştirmek kritik bir adımdır (microservices.io).

Operasyonel gerçeklik: Otomasyon ve gözlemlenebilirlik neden şart?

Mikroservisler, geliştirme hızını artırma potansiyeli sunarken operasyonel yükü de artırabilir. Endüstri raporları, cloud-native benimsemede kültürel/operasyonel zorlukların sıklıkla öne çıktığını gösterir (CNCF Annual Cloud Native Survey 2025). Bu, “mikroservis = sadece mimari karar” değil, aynı zamanda çalıştırma modeli kararı olduğunu hatırlatır.

Minimum operasyonel hazırlık listesi

• CI/CD standardı: Her servis için test, güvenlik kontrolleri ve otomatik dağıtım adımları (mikroservis operasyonel yaklaşımı: AWS).
• Merkezi gözlemlenebilirlik: Log toplama, metrikler, dağıtık izleme (distributed tracing) (operasyonel zorluklar bağlamı: CNCF 2025).
• Hata dayanıklılığı: Dağıtık çağrılarda zaman aşımı (timeout) ve dayanıklılık desenleri (ör. circuit breaker) tasarımın parçası olmalıdır (desen kataloğu: microservices.io; genel mikroservis yaklaşımı: AWS).
• Konfigürasyon yönetimi: Ortam bazlı ayarları koddan ayırma ve gizli bilgileri güvenli yönetme (ilkeler: The Twelve-Factor App).

12-Factor ilkeleriyle pratik kontrol listesi (özellikle mikroservisler için)

The Twelve-Factor App yaklaşımı, bulut uyumlu uygulamalar için uzun süredir referans alınan bir dizi pratik ilke sunar. Mikroservislerde her servis ayrı dağıtım birimi olduğu için bu ilkeler daha da görünür hale gelir.

Hızlı kontrol listesi

• Konfigürasyon: Ortam değişkenleriyle yönetiliyor mu? (kod içine gömülmüş ayarlar risklidir) (12-Factor)
• Bağımlılıklar: Uygulama bağımlılıkları açıkça tanımlı mı? (12-Factor)
• Loglar: Loglar dosyaya değil, standard output’a akıp merkezi sistemde toplanıyor mu? (12-Factor)
• Port binding: Uygulama kendi web sunucusunu bir port üzerinden sunuyor mu? (12-Factor)
• Stateless süreçler: Uygulama instance’ları durum tutmadan yatay ölçeklenebiliyor mu? (12-Factor)

Yaygın tuzaklar (ve nasıl kaçınılır?)

1) Çok erken servisleşme

Ürün henüz sık değişiyorken fazla sayıda servis, koordinasyonu zorlaştırabilir. Önce modüler monolit, sonra ihtiyaç oldukça servis çıkarma yaklaşımı çoğu ekip için daha yönetilebilir bir yoldur (Martin Fowler).

2) Senkron bağımlılıkların artması

Her şey zincirleme senkron çağrılarla ilerlerse, gecikme ve hata olasılığı artar. Dayanıklılık desenleri (ör. circuit breaker) ve net zaman aşımı stratejileri tasarımın parçası olmalıdır (desenler: microservices.io).

3) Veri sınırlarının belirsiz kalması

Servis sınırları net değilse, “bu veri kimin?” sorusu sürekli tartışma yaratır. Bounded context yaklaşımı ve servis başına veri sahipliği prensipleri bu sorunu azaltır (microservices.io; genel mikroservis tanımı için AWS).

Özet: Hangi yaklaşım size daha yakın?

Katmanlı mimari, özellikle erken aşama ürünlerde ve tek uygulama olarak ilerleyen projelerde basitlik ve net sorumluluk ayrımı sağlar (Microsoft). Mikroservisler ise doğru sınırlar, olgun otomasyon ve güçlü operasyonel pratiklerle birleştirildiğinde bağımsız dağıtım, bağımsız ölçekleme ve ekip otonomisi getirebilir (AWS; Sam Newman). Ancak bu kazanımların bedeli çoğu zaman dağıtık sistem karmaşıklığıdır; CAP teoreminin işaret ettiği tutarlılık takasları ve operasyonel gereksinimler göz ardı edilmemelidir (Gilbert & Lynch; CNCF 2025).

Eğer tek bir “başlangıç önerisi” isterseniz: İyi modülerleşmiş bir monolit ile başlayın, gözlemlenebilirlik ve otomasyonu erken kurun, ardından gerçek darboğazlar ve organizasyonel ihtiyaçlar ortaya çıktıkça Strangler gibi kademeli stratejilerle servisleri ayırın (Fowler; microservices.io).

Kaynaklar (seçme)

• Microsoft Azure Architecture Center — Architecture styles
• AWS — What are Microservices?
• microservices.io — Patterns, Principles and Practices
• Martin Fowler — Microservices
• Sam Newman — Building Microservices (overview)
• CNCF Annual Cloud Native Survey 2025
• The Twelve-Factor App
• Gilbert & Lynch (2002) — Brewer’s Conjecture and the Feasibility of CAP