Yazılım Mimarisi
Ölçeklenebilir sistem tasarımı
Mimari, en modern olanı seçmek değil; hangi bedeli ne zaman ödeyeceğinize karar vermektir.
Yazılım mimarisi danışmanlığı, bir sistemin hangi parçalara ayrılacağına, bu parçaların nasıl haberleşeceğine ve hangi kararın sonradan geri alınabileceğine dair bağımsız dış görüştür. Çıktısı bir diyagram değil, gerekçesi yazılı kararlar dizisidir: her kararın maliyeti, riski ve geri dönüş yolu açıkça belirtilir.
Mimari tartışmaları çoğu ekipte teknoloji tartışması gibi görünür ama değildir. "Mikroservise geçelim mi" sorusunun altında genellikle şu yatar: ekip birbirini bekliyor, sürüm çıkmak korkutucu ve kimse sistemin tamamını anlamıyor. Bunlar mimariyle çözülür; ancak doğru teşhis konursa.
Telekomünikasyondan havacılığa, turizmden e-ticarete kadar farklı yük ve risk profillerine sahip sistemlerde çalıştım. Kimini sıfırdan tasarladım, kiminde taşıma projelerini yürüttüm. Bu deneyimin öğrettiği tek şey var: doğru mimari, en yeni olan değil; ekibinizin taşıyabildiği olandır.
Bu sayfa ulusal ölçekte, teknoloji bağımsız bir mimari danışmanlığını anlatıyor. Projenin bütününde yerinde çalışma, ekip kurulumu ve teknoloji seçimi arıyorsanız Antalya yazılım danışmanlığı sayfası daha doğru başlangıç.
Mimarinize birlikte bakalım
Bu çalışma ne zaman gerekli?
Mimari danışmanlığı sürekli bir ihtiyaç değil. Genelde şu üç işaretten biri göründüğünde anlamlı oluyor.
Aynı tartışma üçüncü kez dönüyor
Monolit mi mikroservis mi, hangi veritabanı, hangi kuyruk — aynı soru her çeyrek yeniden açılıyorsa sorun bilgi eksikliği değil, kararı bağlayacak bir çerçevenin olmamasıdır.
Küçük değişiklik büyük risk
Tek satırlık bir düzeltme için üç ekibin onayı ve tam regresyon testi gerekiyorsa, sistemin sınırları yanlış yerden geçiyor demektir. Bu bir disiplin sorunu değil, tasarım sorunudur.
Yeni gelen aylarca üretken olamıyor
İşe alım hızlı ama katkı yavaşsa, sistemin nasıl çalıştığı yalnızca birkaç kişinin kafasında duruyor olabilir. Mimarinin yazılı olmaması en pahalı teknik borçlardan biridir.
Neler yapıyorum?
Mevcut durumun çıkarılması
Kod, veri akışı ve dağıtım hattı üzerinden sistemin gerçekte nasıl çalıştığını çıkarıyoruz — belgelenmiş hâlini değil, çalışan hâlini.
Servis sınırlarının çizilmesi
Sınırları veriye, değişim hızına ve ekip yapısına göre çiziyoruz. Modüler monolit çoğu ekip için mikroservisten daha doğru cevap oluyor.
Mimari karar kaydı (ADR)
Her önemli karar; bağlam, değerlendirilen alternatifler, seçilen yol ve kabul edilen bedel ile birlikte yazılıyor. Altı ay sonra "neden böyle yapmıştık" sorusunun cevabı burada duruyor.
Veri ve entegrasyon tasarımı
Hangi veri nerede sahiplenilir, tutarlılık nerede anlık nerede gecikmeli olur, entegrasyonlar senkron mu asenkron mu — sistemin en zor geri alınan kararları bunlar.
Aşamalı geçiş planı
Büyük yeniden yazım yerine, her adımı tek başına yayına alınabilir ve geri alınabilir parçalara bölen bir yol haritası.
Ekibe devir
Kararı ben verip çekilmiyorum. Gerekçeyi ekiple birlikte kuruyoruz ki sonraki kararları benim olmadığım bir odada da aynı çerçeveyle verebilsinler.
Nasıl ilerliyoruz?
Mimari çalışması, uzun bir analiz dönemi değil; kısa ve karar üreten turlar hâlinde ilerliyor.
Mevcut durumu çıkarma
Sistemi, ekibi ve dağıtım hattını inceliyorum; sorunun mimaride mi başka yerde mi olduğunu netleştiriyoruz.
Kısıtları netleştirme
Bütçe, ekip büyüklüğü, işletme kapasitesi ve yasal kısıtlar. Mimariyi belirleyen şey çoğu zaman bunlar.
Karar ve gerekçe
Alternatifleri bedelleriyle birlikte koyuyoruz; seçilen yol ADR olarak yazılıyor.
Geçiş ve devir
Aşamalı plan devreye giriyor, ekip kararı sahipleniyor. Gerekirse belirli aralıklarla gözden geçiriyoruz.
Mimari kararlarda en sık yapılan üç hata
Kararın gerekçesi yazılmıyor. Ekipler kararı verir, uygular ve gerekçeyi unutur. Bir yıl sonra o karar "kötü tasarım" gibi görünür; oysa o gün geçerli bir kısıt vardı. Gerekçe yazılı olmadığı için yeni ekip aynı yolu yeniden yürür ve aynı bedeli yeniden öder. Mimari karar kaydı tam olarak bunu engeller: karar değil, kararın bağlamı saklanır.
Mikroservis, ekip sorununa teknik cevap olarak seçiliyor. Ekipler birbirini bekliyorsa sorun genelde dağıtım hattında ve sahiplikte olur; sistemi yirmi parçaya bölmek bu sorunu çözmez, ağ üzerinden yeniden üretir. Üstelik dağıtık sistem, tek parça sistemin bütün sorunlarını devralır ve üzerine ağ gecikmesi, kısmi arıza ve dağıtık izleme yükü ekler. Ekip sayısı ve sahiplik netleşmeden servis sayısını artırmak neredeyse her zaman erken bir karardır.
Geri alınamaz kararlar erken veriliyor. Kararları ikiye ayırmak işe yarar: geri alınabilir olanlar (kütüphane seçimi, kod düzeni) ve alınamayanlar (veri modeli, servis sınırları, veri sahipliği). Birincilerde hızlı davranıp deneyebilirsiniz; ikincilerde acele etmenin bedeli yıllarca ödenir. Pratikte ekipler tam tersini yapıyor: kütüphane seçimini haftalarca tartışıp veri modelini bir öğleden sonra kararlaştırıyor.
Bu üçü düzeldiğinde mimari tartışmaları kısalır, çünkü tartışmanın çerçevesi ortak hâle gelir. Kararlar bulut tarafında da karşılık bulacaksa cloud-native geliştirme ve CI/CD ve DevOps başlıkları doğal devamı; ekibin bu çerçeveyi kendi başına sürdürmesi için mentorluk ve ekip eğitimi ayrı bir çalışma.
Sık sorulan sorular
Yazılım mimarisi nedir, kodlamadan farkı ne?
Kodlama, seçilen çözümün nasıl yazılacağıyla ilgilenir; mimari, hangi çözümün seçileceği ve sistemin hangi parçalara ayrılacağıyla. Mimari kararlar geri alınması en pahalı kararlardır: bir fonksiyonu bir günde yeniden yazabilirsiniz, veri modelini ya da servis sınırlarını yeniden çizmek aylar sürer.
Monolit mi mikroservis mi seçmeliyim?
Ekip sayısı beşin altındaysa ve sistem tek bir iş alanına hizmet ediyorsa, modüler monolit neredeyse her zaman daha doğru başlangıçtır. Mikroservis, farklı ekiplerin birbirini beklemeden yayına çıkması gerektiğinde ve sistemin parçaları gerçekten farklı hızlarda değiştiğinde anlam kazanır. Servis sayısı bir hedef değil, bir sonuçtur.
Mimari karar kaydı (ADR) nedir, gerçekten gerekli mi?
ADR, bir mimari kararı bağlamı ve alternatifleriyle birlikte kaydeden kısa bir belgedir; genelde bir sayfayı geçmez. Gerekli olmasının sebebi şu: ekipler değişir, karar kalır. Gerekçesi yazılmamış bir karar, birkaç yıl sonra hatalı görünür ve gereksiz yere geri alınır. ADR bu maliyeti çok düşük bir yazma eforuyla ortadan kaldırır.
Mevcut sistemi baştan yazmak mı, iyileştirmek mi daha doğru?
Baştan yazma kararı, çalışan bir sistemi durdurup bilinmeyen bir riske girmek demektir ve tahmin edilenden neredeyse her zaman uzun sürer. Çoğu durumda doğru yol, sistemi sınırlarından başlayarak parça parça devralmak: yeni işlevi yeni yapıda yazıp eskisini kademeli olarak devre dışı bırakmak. Baştan yazma yalnızca teknoloji desteği tamamen bittiğinde ya da iş modeli değiştiğinde savunulabilir.
Bu çalışma ne kadar sürer?
Mevcut durumun çıkarılması ve ilk kararların yazılması tipik olarak iki ila dört hafta arasında sürüyor. Aşamalı geçiş planının uygulanması ise sistemin büyüklüğüne bağlı; burada da amaç uzun bir proje değil, her adımı tek başına yayına alınabilir parçalara bölmek. Süre net değilse ilk görüşmede kapsamı birlikte daraltıyoruz.
Antalya dışından da çalışıyor musunuz?
Evet. Mimari çalışmasının büyük kısmı uzaktan yürütülebiliyor; kod incelemesi, karar toplantıları ve ADR yazımı için yerinde olmak şart değil. Türkiye genelinde uzaktan, Antalya ve çevresinde gerektiğinde yerinde çalışıyorum.
Mimari bir karar önünüzde duruyorsa, yalnız vermeyin
Mevcut sisteminize ve önünüzdeki karara birlikte bakalım; alternatifleri bedelleriyle konuşalım. İlk görüşme ücretsiz.
Mimari için ön görüşme talep edinBu mimari kararları projenizin bütününde, ekip ve teknoloji seçimiyle birlikte ele almak isterseniz Antalya yazılım danışmanlığı sayfasına bakabilirsiniz.