Yazılım mimarisi, bir projeye kod yazmaya başlamadan önce alınan üst düzey tasarım kararlarının bütünüdür: hangi programlama dili, hangi veritabanı, sistem parçaları birbirine nasıl bağlanacak, hangi güvenlik ve performans gereksinimleri karşılanacak. Bu kararları genelde bir yazılım mimarı alır ve projenin geri kalanı bu temel üzerine inşa edilir.
Yazılım Mimarisi Neden Önemli?
İyi kurulmamış bir mimari kısa vadede fark etmez ama proje büyüdükçe kendini gösterir: yeni özellik eklemek yavaşlar, performans sorunları büyür, ekip değişikliklerinde kod kimse tarafından tam anlaşılmaz hale gelir. Mimari kararlar erken alınır ama sonuçları projenin ömrü boyunca sürer.
Modüler Tasarım ve Yapısal Kalıplar
Modüler tasarım, farklı tasarım alternatifleri oluşturmak için tek bir modül veya birden fazla modül kullanma imkanı sunar; yazılım geliştirmeyi hızlandıran bir yapım yöntemi olarak bilinir. Modüler tasarımın içinde yer alan yedi temel yapısal kalıp şunlardır:
- Adaptör Kalıp (Adapter Pattern)
- Köprü Kalıp (Bridge Pattern)
- Bileşik Kalıp (Composite Pattern)
- Dekoratör Kalıp (Decorator Pattern)
- Vitrin Kalıp (Facade Pattern)
- Sineksıklet Kalıp (Flyweight Pattern)
- Vekil Kalıp (Proxy Pattern)
Yazılım Mimarisi Prensipleri
SOLID İlkesi
SOLID, yazılım tasarımlarını anlaşılır ve sürdürülebilir hale getirmeyi amaçlayan beş tasarım ilkesinin kısaltmasıdır:
- SRP - Tek Sorumluluk Prensibi: Karmaşıklığı en aza indirmeyi hedefler.
- OCP - Açık-Kapalı Prensibi: Mevcut kodun bozulmasını önler, yeni özellik eklerken kullanışlıdır.
- LSP - Liskov Yerine Koyma Prensibi: Alt sınıfların üst sınıfların nesneleriyle uyumlu olmasını destekler.
- ISP - Arayüz Ayrımı Prensibi: İstemci sınıflarının gereksiz davranışları uygulamaktan kaçınmasını amaçlar.
- DIP - Bağımlılığın Tersine Çevrilmesi Prensibi: Düşük düzeyli sınıfları farklı sınıflarla kullanmayı kolaylaştırır.
Diğer Prensipler
- DRY - Kendini Tekrarlama: Kod tekrarını azaltmayı hedefler.
- KISS - Basit Tut: Gereksiz karmaşıklıktan kaçınmayı amaçlar.
- YAGNI - İhtiyacınız Yok: İleride gerekebilir diye şimdiden özellik eklemekten kaynaklanan karmaşıklıktan kaçınmayı amaçlar.
- Değişenleri Kapsülle: Değişikliklerin etkisini en aza indirmeyi hedefler.
- Kalıtım Yerine Kompozisyon: Ortak kodu paylaşmak için kalıtım yerine kodun paylaşıldığı bir yapı kurmayı önerir.
AppFellas
Fikrinizi konuşalım.
Ücretsiz keşif görüşmesinde projenizi, bütçenizi ve zaman çizelgenizi netleştirelim.
Sık Kullanılan Mimari Modeller
| Model | Nasıl Çalışır | Ne Zaman Tercih Edilir |
|---|---|---|
| Katmanlı (N-Katmanlı) | Yazılım, her biri belirli bir görevi üstlenen katmanlara ayrılır (sunum, iş mantığı, veri erişimi) | Kurumsal, orta ölçekli uygulamalarda; ekip standart bir yapı istiyorsa |
| Olay Güdümlü | Sistem, olayların tetiklediği tepkiler üzerine kurulur | Gerçek zamanlı bildirim, IoT veya yüksek eşzamanlı sistemlerde |
| Mikrokernel | Temel işlevler çekirdekte, ek özellikler eklenti olarak çalışır | Eklenti (plugin) mimarisi gerektiren ürünlerde (IDE, CMS gibi) |
| Mikro Hizmet (Microservices) | Uygulama, her biri bağımsız çalışan küçük servislere bölünür | Büyük ekipler, bağımsız dağıtım ve ölçeklendirme gerektiğinde |
| Uzay Temelli | Veri ve işlem yükü farklı düğümlere dağıtılır | Çok yüksek trafik ve yatay ölçeklenme gereken sistemlerde |
Monolith mi, Mikroservis mi?
Çoğu yeni proje tek parça (monolith) bir yapıyla başlar; ekip küçükken ayrı servisleri yönetmenin operasyonel yükü, getirdiği faydadan daha fazla olur. Mikroservise geçiş genelde şu sinyaller ortaya çıktığında konuşulur: birden fazla ekip aynı kod tabanında birbirini bekliyor, bir modülün trafiği diğerlerinden çok daha yüksek ve ayrı ölçeklenmesi gerekiyor ya da bir bölümü farklı bir dille yeniden yazmak gerekiyor.
Mimari Kararı Kim Alır?
Büyük şirketlerde bu kararları genelde "yazılım mimarı" unvanlı bir kişi alır. Küçük ekiplerde ise ayrı bir unvan olmayabilir; bu sorumluluk kurucu geliştirici veya teknik lidere düşer. Unvan fark etmez, önemli olan bu kararların bilinçli ve dokümante edilerek alınmasıdır; aksi halde her yeni geliştirici kendi tercihini dayatır ve sistem zamanla tutarsızlaşır.
Ne Zaman Dışarıdan Bir Yazılım Mimarına İhtiyaç Duyarsınız?
Erken aşama bir girişimseniz ve ekipte bu kararları önceden almış biri yoksa, yanlış bir mimari seçimi ilerideki her özelliği daha pahalı hale getirebilir. AppFellas gibi yazılım geliştirme stüdyolarıyla çalışmak, bu kararları projenin başında birlikte almanızı sağlar. Tamamladığımız projelere buradan göz atabilirsiniz.
Sık sorulan sorular
Yazılım mimarisi ile yazılım tasarımı aynı şey mi?
Hayır ama iç içe geçerler. Mimari, sistemin genel yapısı ve büyük parçaları hakkındaki kararlardır (örneğin monolith mi mikroservis mi). Tasarım ise bu yapının içindeki daha küçük ölçekli kararlardır.
Küçük bir proje için mimari planlamaya gerek var mı?
Evet ama kapsamı küçük tutulmalı. Basit bir MVP için karmaşık bir mikroservis mimarisi kurmak zaman kaybettirir; yine de veritabanı seçimi ve temel klasör yapısı gibi kararlar baştan alınmalı.
SOLID prensiplerini uygulamak performansı düşürür mü?
Genelde hayır; SOLID kodun okunabilirliğini ve bakımını hedefler, çalışma zamanı performansını doğrudan etkilemez. Aşırı soyutlama katmanı eklemek performansı etkileyebilir ama bu SOLID'in kendisinden çok yanlış uygulamadan kaynaklanır.
Mimariyi sonradan değiştirmek mümkün mü?
Mümkün ama maliyetli. Bu yüzden erken aşamada temel kararları (dil, veritabanı, servis sınırları) doğru almak, sonradan yeniden yazmaktan çok daha ucuza gelir.
