Yazılım mimarisi nedir? Türleri ve karar kriterleri

Yazılım mimarisi nedir?

Yazılım mimarisi, bir yazılım sisteminin parçalarını, bu parçalar arasındaki ilişkileri ve teknik kararların çerçevesini tanımlar. Ben mimariyi, ekibin yıllarca uymaya devam edeceği teknik sınırlar ve özgürlükler seti olarak görürüm. Doğru kurduğunuzda, yeni özellik eklemek kontrollü gider ve ekip neyi nereye koyacağını bilir.

Bir yazılım projesini tasarlarken aslında üç düzeyde düşünürsünüz. Birincisi iş hedefleri, ikincisi teknik kısıtlar, üçüncüsü günlük kod kararları. Yazılım mimarisi bu üç düzeyi birbirine bağlayan iskelet rolünü üstlenir. Kodun klasör yapısından çok daha geniş bir kapsamı vardır. Ağ topolojisi, veri depolama stratejisi, bileşenlerin konuşma biçimi ve hata senaryolarının ele alınışı bu çerçeveye girer.

Yanlış anlaşılan noktalardan biri, mimarinin sadece diyagram çizmekten ibaret sanılması. Ben diyagramı, kararların görünür hâli olarak kabul ederim. Esas kritik kısım, hangi bileşeni neden ayırdığınız, hangi modülü birlikte tuttuğunuz ve performans ile güvenliği nasıl dengelediğinizdir. Bu kararlar, ekibin üretkenliğini ve sistemin bakım maliyetini doğrudan etkiler.

Kurumsal bir örnek üzerinden gideyim. Sipariş, fatura ve stok modülleri olan bir ticari uygulamada, bu modüllerin tek bir dev kod tabanı mı, yoksa bağımsız bileşenler mi olacağı mimari karardır. Aynı işlevi hem modüler monolit hem de mikroservis ile kurabilirsiniz. Aradaki fark, takım yapısına, büyüme hızına ve risk iştahına göre anlam kazanır. Bu yüzden mimariyi, tek doğru cevabı olmayan ancak iyi ve kötü tercihleri olan bir tasarım alanı gibi ele almak gerekir.

Pratikte mimari, şu başlıkları kapsar:

• Bileşenlerin sınırları ve sorumlulukları
• İletişim biçimleri (senkron, asenkron, mesajlaşma)
• Veri saklama ve erişim stratejileri
• Dağıtım modeli ve ortam topolojisi
• Çapraz kesen kaygılar: güvenlik, gözlemlenebilirlik, hata yönetimi

Ben iyi bir mimarinin, kod yazan kişiye gereksiz kural yüklemeyen, ama kritik konularda açık sınırlar çizen bir denge kurması gerektiğini savunuyorum. Aksi durumda ya kaos oluşur ya da ekip hareket edemez hâle gelir.

Yazılım mimarisi tanımı

Yazılım mimarisi için kısa bir tanım vermem gerekirse şöyle söylerim. Bir yazılım sisteminin yüksek seviyeli yapısını, bileşenlerini, bu bileşenlerin etkileşimini ve uzun vadeli teknik kararlarını belirleyen çerçeve, mimaridir. Bu çerçeve, sadece bugünkü işlevleri değil, gelecekteki değişiklikleri de gözetir. Bu yüzden mimariyi, sistemin zaman içindeki evrim planı gibi okumak daha sağlıklıdır.

Kodlama ile yazılım mimarisi arasındaki farklar

Kodlama ile mimari çoğu zaman iç içe geçer, ancak odak noktaları farklıdır. Kodlama, belirli bir işlevi hayata geçiren somut sınıflar, fonksiyonlar ve testler üretir. Mimari ise hangi modülün hangi sorumluluğu alacağını, veri akışının nasıl ilerleyeceğini ve sınırların nerede çizileceğini belirler. Kod değişebilir, hatta dil bile değişebilir; mimari kararlar ise daha uzun ömürlüdür ve ekip davranışını yönlendirir. Mevcut bir sistemin bu kararlarını dışarıdan bir gözle sınatmak istediğinizde yazılım mimarisi danışmanlığı bu işi üstlenir.

Yaygın yazılım mimarisi türleri

Mimari konuşmalarında en sık sorulan soru, “Bu sistem için hangi mimari daha uygun?” sorusu. Tek bir doğru yok, ancak bazı yaygın yaklaşımlar var. Katmanlı mimari, mikroservis, olay güdümlü mimari ve modüler monolit, kurumsal projelerde en yaygın dört yapı. Her biri farklı risk ve kazanım seti sunar. Örneğin, hızlı büyüyen bir ürün ile regülasyon baskısı yüksek bir kurumsal sistem aynı mimariyi nadiren paylaşır.

Bu mimari türlerini değerlendirirken, sadece teknik özelliklere bakmak yetmez. Ekibin deneyimi, operasyon kapasitesi, gözlemleme araçları ve hata toleransı da resmin parçasıdır. Olay güdümlü bir yapı, yüksek işlem hacimli sistemlerde esneklik sağlayabilir. Fakat gözlemleme ve hata ayıklama tarafında disiplinli olmazsanız, üretim sorunlarını izlemek zorlaşır. Ben bu nedenle, mimari seçimi yaparken her zaman operasyonel gerçekleri masaya koymayı öneririm.

Aşağıda dört yaklaşımı, karar verirken işinizi kolaylaştıracak şekilde yan yana özetliyorum.

Bu tabloyu, ilk değerlendirme filtresi gibi düşünebilirsiniz. Ayrıntıya indikçe, veri yapınız, ağ sınırlarınız ve güvenlik gereksinimleriniz kararınızı daha da netleştirir. Şimdi bu mimari türlerine tek tek bakalım.

Katmanlı mimari

Katmanlı mimari, geleneksel kurumsal uygulamalarda hâlâ güçlü bir yer tutar. Sunum, iş mantığı ve veri erişimi katmanları birbirinden ayrılır. Böylece ekip, arayüz ile veri katmanını bağımsız geliştirebilir. Ben bu yapıyı, net sınırlar isteyen ama operasyon ekibi sınırlı olan kurumlar için mantıklı buluyorum. Ancak katmanları sadece teknik katman olarak değil, alan odaklı modüllerle birlikte düşünmek gerekir.

Mikroservis mimarisi

Mikroservis mimarisi, her iş alanını bağımsız dağıtılabilir servisler hâline getirir. Her servis kendi veri depolamasına ve yaşam döngüsüne sahiptir. Bu yapı ölçeklenebilirlik ve bağımsız dağıtım avantajı sağlar. Fakat ağ trafiği, gözlemlenebilirlik ve dağıtık hata yönetimi konularında ciddi disiplin ister. Ekibin DevOps ve otomasyon kültürü zayıfsa, bu mimari tercih çoğu zaman gereğinden pahalıya patlar. Bu geçişte verilecek kararları mikroservis mimarisinde pratik kararlar yazısında ayrıntılı anlattım.

Olay güdümlü mimari

Olay güdümlü mimari, sistemin kalbine olay akışlarını yerleştirir. Servisler doğrudan çağrı yerine, ürettikleri olayları bir mesaj altyapısına yazar. Diğer bileşenler bu olayları dinler ve tepki verir. Bu yaklaşım, yüksek hacimli işlem ve gevşek bağlılık istediğiniz senaryolarda güçlüdür. Ancak olay şemalarının yönetimi, versiyonlama ve hata geri alma stratejileri için net kurallar koymanız gerekir.

Modüler monolit mimari

Modüler monolit mimari, tek bir dağıtım birimi içinde sıkı modülerlik kurmaya odaklanır. Uygulama tek bir işlem olarak çalışır, fakat içeride alan odaklı modüller keskin sınırlarla ayrılır. Ben özellikle büyüme potansiyeli olan ama henüz mikroservis karmaşıklığına hazır olmayan ekipler için bu yaklaşımı güçlü buluyorum. İleride ihtiyaç doğarsa, bu modülleri bağımsız servislere ayırmak çok daha kontrollü ilerler.

Yazılım mimarisi seçim kriterleri

Bir mimari türünü seçerken, sadece trendleri takip etmek ciddi risk taşır. Ben karar verirken dört ana eksene bakarım. Ekip yapısı, iş gereksinimleri, operasyon yetkinliği ve gelecek planı, mimari seçimde belirleyici dört başlıktır. Bu başlıkları netleştirmeden, teknik bir diyagram çizmek bana eksik bir egzersiz gibi gelir. Örneğin, deneyimi sınırlı bir ekibe karmaşık dağıtık yapı emanet etmek, orta vadede teslimat hızını düşürür.

Somut ilerlemek için, küçük ama net bir adım listesi kullanabilirsiniz.

1. İş hedeflerini ve kısıtları yazılı hâle getirin.
2. Ekipteki rol ve yetkinlik haritasını çıkarın.
3. Veri hacmini ve performans beklentilerini kabaca modelleyin.
4. Operasyon ve gözlemleme araçlarınızı envanterleyin.
5. İki veya üç mimari aday belirleyip, artı eksi analizi yapın.

Kendi ürünümüz YouContent360'ta kararı belirleyen kriter, çalıştığımız platformun bir sınırı oldu. Rakip sayfaları tarayan işlev bütün adresleri tek bir fonksiyon çağrısında paralel işliyordu. Bot korumalı sitelerde tek bir adresin denemeleri üç dakikayı bulunca toplam süre, platformun bir çağrıya tanıdığı yaklaşık 150 saniyeyi aşıyordu. Sorgu yedi dakikadan uzun takılı kalıyor, sonunda başarısız sayılıyor, kullanıcı bu arada hiçbir şey görmüyordu. Her şeyi tek çağrıda bitiren tasarımı eledik: adresler önce kayda geçiyor, her biri ayrı güncelleniyor, korumaya takılanlar yeniden deneme kuyruğuna gidiyor. Süre sınırına takılan bir çağrı artık o ana kadar yapılan işi kaybetmiyor.

Bu adımlar, tartışmayı soyut mimari isimlerinden çıkarıp somut kararlara taşır. Özellikle veri modeliniz ve ağ sınırlarınız, güvenlik ve performans gibi konularda sizi bazı seçeneklere daha yakınlaştırır. Şimdi iki kritik kritere biraz daha yakından bakalım.

Ekip yapısı

Mimari seçimde ilk baktığım şey, ekip yapısı ve deneyim dağılımıdır. Birden fazla otonom ekip varsa, mikroservis veya olay güdümlü mimari daha anlamlı hâle gelebilir. Tek bir çekirdek ekip, sınırlı DevOps deneyimi ve kısıtlı operasyon desteği varsa, modüler monolit veya sade bir katmanlı yapı genelde daha sağlıklı olur. Ayrıca ekip içindeki alan bilgisi dağılımı da önemlidir; belirli alanlara sahiplenme verebiliyorsanız, modüler sınırlar daha net oturur. Yeni mezunlarla yürüttüğüm Tech Builder Program'da mimariyi de bu ilkeyle seçtik: dört kişilik ekipte her modülün bir sahibi vardı ve sınırlar teknolojiye göre değil, ekibe göre çizildi.

Proje gereksinimleri

Her yazılım projesini kendi bağlamında okumak gerekir. Gerçek zamanlı işlem gerektiren, yüksek hacimli veri akışına sahip sistemler için olay güdümlü mimari güçlü bir adaydır. Regülasyon baskısı yüksek, denetlenebilirlik ön planda olan kurumsal çözümleri ise çoğu zaman daha muhafazakâr yapılarla kurmak daha mantıklıdır. Ayrıca dış entegrasyon sayısı, güvenlik gereksinimleri ve beklenen tepki süreleri, mimari tercih üzerinde doğrudan etki yaratır. Ben gereksinim analizini, sadece fonksiyonel maddeler listesi değil, sistemin davranış profilini tanımlayan bir belge olarak ele almayı faydalı buluyorum.

Sık sorulan sorular

Mimari seçiminiz şirketin genel teknoloji yönüyle birlikte ele alınacaksa yazılım danışmanlığı sayfasına bakabilirsiniz.