Yazılım mimarisi ve çözüm tasarımı
İş gereksinimlerini sağlam bir teknik yapıya dönüştürüyoruz. Mimari kararlar yalnızca başlangıcı değil; işletimi, güvenliği, entegrasyonu ve bir sistemin karşılaşacağı değişimi de hesaba katar.
Kısaca Yazılım mimarisi ve çözüm tasarımı.
Kararınız için en önemli noktalar: ne zaman uygun olduğu, nasıl ilerlediğimiz ve nelere dikkat ettiğimiz.
- Ayrı bir mimari aşaması değer, eğer
- birden fazla sistem, hassas veriler, yüksek erişilebilirlik veya uzun bir kullanım ömrü söz konusuysa.
- Daha yalın bir yaklaşım yeterlidir, eğer
- tek ekiple, az sayıda arayüzle ve düşük işletim riskiyle yönetilebilir bir sistem geliştiriliyorsa.
- Tipik çıkış noktası
- mevcut altyapıya eklenecek yeni bir sistem, sınırlarına dayanmış büyümüş bir sistem ya da satın alma mı geliştirme mi sorusunun henüz yanıtlanmamış olması.
- Tercih ettiğimiz başlangıç noktası
- net sınırlara sahip modüler bir monolit; dağıtık yapı yalnızca somut bir gereksinim bunu talep ettiğinde.
- Tipik riskler
- modaya göre mimari, gerekçesiz dağıtık yapı, sonradan akla gelen işletim ve belgelenmemiş kararlar.
- Neyi optimize ediyoruz
- Değiştirilebilirlik, izlenebilir işletim, net sorumluluklar ve geri alınabilir kalan kararlar.
- Bilinçli olarak kaçındıklarımız
- Kendi başına amaç olan mimari, karar içermeyen diyagramlar ve gereksinimlerden önce yapılan teknoloji seçimi.
- Sonunda elinizde olan
- değerlendirilmiş alternatifler, belgelenmiş kararlar ve adım adım bir plan içeren hedef mimari.
Nedir — ve neleri kapsar?
Yazılım mimarisi, bir sistemin yapısına ilişkin, sonradan değiştirilmesi maliyetli olan kararların bütünüdür: sınırlarının nereden geçtiği, bileşenlerin nasıl birlikte çalıştığı, verilerin nasıl aktığı ve sistemin nasıl işletildiği. Çözüm tasarımı, iş gereksinimlerini bu yapıya dönüştürür. Batunet bu kararları gerekçeli biçimde alır, alternatifleri ve ödünleşimleri (trade-off) görünür kılar ve bir yolun neden seçildiğini belgeler.
Hizmet kapsamı
- Sistem sınırları, bağlam ve sorumluluklar
- İş alanları (domain) ve temel iş kuralları
- Bileşenler, arayüzler ve entegrasyonlar
- Veri modelleri ve veri akışları
- Güvenlik ve yetkilendirme konseptleri
- Ölçeklenebilirlik, erişilebilirlik, işletim ve dağıtım
- Build-versus-buy kararları
- Mimari alternatifler ve ödünleşimleri
- Teknik borç ve modernizasyon yolları
- Belgelenmiş kararlar (ADR'ler)
Ne zaman uygun — ne zaman değil?
Projeye uyan yolu öneririz — bu hazır bir ürün olsa bile.
Uygun
- Yeni bir sistemin uygulamalar, veriler ve arayüzlerden oluşan mevcut bir yapıya uyum sağlaması gerekiyor.
- Güvenlik, veri koruma, erişilebilirlik veya izlenebilirlik istek değil, kesin gereksinim.
- Büyümüş bir sistem sınırlarına dayanıyor ve modernize mi edileceği, genişletileceği mi yoksa yerine başka bir sistem mi konacağı belli değil.
- Birden fazla çözüm yolu mümkün ve kararın gerekçeli ve izlenebilir biçimde verilmesi isteniyor.
Uygun değil
- Tek ekibi, az sayıda arayüzü ve düşük işletim riski olan küçük bir sistem. Orada mimari, haklı olarak ayrı bir aşamada değil, uygulama sürecinde oluşur.
- Bir varsayımı test edip ardından atılacak bir prototip. Orada ileriye dönük mimari çalışması boşa gider.
- Gereksinimler büyük ölçüde henüz açık. Bu durumda önce bir gereksinim analizi mantıklıdır — netleşmemiş bir temel üzerine kurulan mimari, varsayımları kalıcı hâle getirir.
Kod yazılmadan önce verilen kararlar.
Teknolojinin ne yapabildiği değil, onu neden bu şekilde kullandığımız.
İş alanına göre sınırlar
Sistemleri ve modülleri teknik katmanlara göre değil, iş alanı sorumluluklarına göre ayırıyoruz. İyi bir sınır; kuralların, verilerin ve değişiklik nedenlerinin farklılaştığı yerdedir — böylece değişiklikler yerel kalır.
Basit başla, dağıtık yapıyı gerekçelendir
Modüler bir monolit, projelerin çoğu için sağlam bir başlangıç noktasıdır. Ayrı servisleri modern sayıldığı için değil; farklı yük, erişilebilirlik veya ekip ihtiyaçları bunu somut olarak gerektirdiğinde devreye alıyoruz.
İşletim tasarımın parçasıdır
Bir sistemin nasıl yayına alınacağı, izleneceği, yedekleneceği ve geri yükleneceği tasarım aşamasında belirlenir. Bu yüzden işletim ve güvenlik gereksinimleri iş gereksinimlerinin arkasında değil, yanında yer alır.
Kararlar yazıya dökülür
Temel kararları Architecture Decision Record olarak kayda alıyoruz: bağlam, alternatifler, seçim ve sonuçlar. Böylece sistemin neden böyle olduğu — sonradan üzerinde çalışacaklar için de — izlenebilir kalır.
Erken fark ettiğimiz riskler.
Bu tür sistemlerde tipik olarak neyin ters gittiği — ve bunu canlı ortamda görünür hâle gelmeden nasıl önlediğimiz.
Modaya göre mimari
- Neden
- Kalıplar ve platformlar, gereksinimler gerektirdiği için değil, yaygın ya da yeni oldukları için seçilir. Bedeli ancak işletimde ve sürekli geliştirmede ortaya çıkar.
- Erken uyarı işaretleri
- Bir teknolojinin gerekçesi gereksinimler yerine trendlere dayanır; bir yapı taşının hangi problemi çözdüğünü kimse söyleyemez.
- Nasıl önlüyoruz
- Her temel karar gereksinimlere göre gerekçelendirilir ve en az bir alternatifle karşılaştırılır; olgun teknoloji yeni teknolojiye göre önceliklidir.
- Ödünleşim
- Bedeli: Yeniliklere daha az alan. Farklı durum: Yeni bir teknoloji somut bir problemi kanıtlanabilir biçimde daha iyi çözüyorsa — o zaman bilinçli ve belgelenmiş olarak.
Dağıtık monolit
- Neden
- Bir sistem, iş alanı sınırları oturmadan erkenden çok sayıda servise bölünür. Servisler birbirine bağımlı kalır — üstüne bir de ağ ve işletim yükü eklenir.
- Erken uyarı işaretleri
- Değişiklikler birden fazla servisin koordineli dağıtımını gerektirir; bir servisin çökmesi diğerlerini de durdurur; veriler servisler arasında senkron olarak gidip gelir.
- Nasıl önlüyoruz
- Sınırlar önce tek bir kod tabanı içinde denenir. Bir servis ancak yük, erişilebilirlik veya ekip yapısı bunu somut olarak gerektirdiğinde ayrılır.
- Ödünleşim
- Bedeli: Başlangıçta tek tek parçaların bağımsız ölçeklenememesi. Farklı durum: Parçaların yük veya erişilebilirlik gereksinimleri kanıtlanabilir biçimde çok farklıysa.
Sonradan akla gelen işletim
- Neden
- Mimari işlev kapsamına göre tasarlanır. Dağıtım, izleme, yedekleme ve geri yükleme ancak yayına almadan kısa süre önce eklenir — ve sonradan eklenmeleri pahalıdır.
- Erken uyarı işaretleri
- Üzerinde anlaşılmış bir geri yükleme süresi yok; dağıtımlar elle yapılıyor; hata durumunda nedeni bulmak için log ve metrik yok.
- Nasıl önlüyoruz
- İşletim gereksinimleri iş gereksinimleriyle birlikte toplanır ve mimaride yanıtlanır — test edilmiş bir geri yükleme yolu da dâhil.
- Ödünleşim
- Bedeli: İlk görünür faydadan önce yapılan iş. Farklı durum: Kısa ömürlü bir prototip geliştiriliyorsa — o zaman asgari düzeyde, ama bilinçli bir kararla.
Hafızası olmayan kararlar
- Neden
- Mimariye ilişkin kararlar toplantılarda alınır ve hiçbir yere kaydedilmez. Sonradan bir şeyin neden böyle yapıldığını — ve bu nedenin hâlâ geçerli olup olmadığını — kimse bilmez.
- Erken uyarı işaretleri
- “Neden” sorularına kişi isimleriyle cevap verilir; değişikliklerden belirsizlik yüzünden kaçınılır ya da ilk gerekçeler bilinmeden yapılır.
- Nasıl önlüyoruz
- Temel kararlar bağlam, alternatifler ve sonuçlarıyla kısa ADR'ler olarak belgelenir ve gerektiğinde açıkça yenileriyle değiştirilir.
- Ödünleşim
- Bedeli: Her temel kararda yazma disiplini. Farklı durum: Bir karar kolayca geri alınabiliyorsa kısa bir not yeterlidir.
Uygulamadan önce netleştirdiğimiz sorular.
Mimariyi araç seçiminden çok sizin yanıtlarınız şekillendirir.
Mimariyi en çok hangi gereksinimler şekillendiriyor?
- Neden önemli
- Her gereksinim mimari açıdan önemli değildir. Birkaç tanesi — veri koruma, erişilebilirlik, entegrasyonlar, beklenen değişim — yapıyı belirler.
- Tipik sonuç
- Bu belirleyicileri açıkça adlandırıyor ve her temel kararı kişisel tercihlerle değil, onlarla gerekçelendiriyoruz.
Sistemin iş alanı sınırları nereden geçiyor?
- Neden önemli
- İş alanına göre çizilen sınırlar değişiklikleri yerel tutar. Teknik katmanlara göre çizilen sınırlar ise her iş değişikliğini tüm sisteme yayar.
- Tipik sonuç
- Modülleri — ve gerektiğinde servisleri — bu sınırlar boyunca ayırıyor ve hangi verinin esas kaynağının hangi sistem olduğunu belirliyoruz.
Hangi kararları geri almak pahalıdır?
- Neden önemli
- Veri modeli, arayüz sözleşmeleri ve platform seçimi sonradan ancak yüksek eforla değiştirilebilir. Diğer pek çok şey ise ucuza düzeltilebilir.
- Tipik sonuç
- Pahalı kararları özenle ve belgeleyerek alıyoruz; ucuz olanları ise daha fazla bilgi edinilene kadar bilinçli olarak açık tutuyoruz.
Sistem neye dayanmalı — ve neyin kesintiye uğramasına izin verilebilir?
- Neden önemli
- Beklenen yük, gereken erişilebilirlik ve tolere edilebilir kesinti süresi, işletimin eforunu ve maliyetini önemli ölçüde belirler.
- Tipik sonuç
- Bu değerleri birlikte belirliyor ve işin gerçekten ihtiyaç duyduğundan fazla yedeklilik tasarlamıyoruz — ama daha azını da.
Neyi kendimiz geliştiriyoruz, neyi satın alıyor veya kullanıyoruz?
- Neden önemli
- Özel geliştirme, fark yarattığı yerde kendini amorti eder. Standart problemler için olgun ürünler ve hizmetler çoğu zaman daha ucuz ve daha güvenlidir.
- Tipik sonuç
- Her bileşen için ayrı karar veriyor, bunun hangi bağımlılığı doğurduğunu ve sonradan bir geçişin nasıl olacağını kayda alıyoruz.
Sistem bugünkü durumundan hedef mimariye nasıl ulaşacak?
- Neden önemli
- Oraya giden bir yolu olmayan hedef mimari, bir diyagram olarak kalır. Mevcut sistemlerde geçiş çoğu zaman hedefin kendisinden daha zordur.
- Tipik sonuç
- Her adımın kendi başına işletilebildiği ve geri alınabilir kaldığı kademeli geçişler planlıyoruz.
Tasarımdan işletime.
Sistemin yalnızca çalışması yetmez, işletimde de ayakta kalması gerekir. Her önerinin bir bedeli vardır — ve farklı karar verdiğimiz durumlar da.
Sistem bağlamı ve bileşenler
Hangi sistemlerin, kullanıcıların ve iş ortaklarının işin içinde olduğunu, sistemin nerede başlayıp nerede bittiğini ve hangi bileşenin hangi sorumluluğu taşıdığını tanımlıyoruz.
Ödünleşim · Bedeli: Şimdiye kadar dile getirilmemiş sorumluluklar üzerinde uzlaşma. Farklı durum: Çevre sistemleri olmayan bağımsız bir sistem geliştiriliyorsa kısa bir özet yeterlidir.
Veriler ve entegrasyonlar
Veri modelini, veri akışlarını ve arayüzleri birlikte tasarlıyoruz: Hangi verinin esas kaynağı hangi sistem ve bir bağlantı kesildiğinde ya da veriyi iki kez gönderdiğinde ne olur?
Ödünleşim · Bedeli: Doğrudan bağlantı yerine çeviri katmanları ve net sözleşmeler. Farklı durum: İki bileşen birlikte geliştirilip birlikte yayına alınıyorsa daha sıkı bir bağlılık savunulabilir.
Güvenlik ve yetkiler
Roller, yetkiler, veri ve kiracı (tenant) ayrımı ile gizli bilgilerin (secret) yönetimi sonradan eklenen bir şey değil, mimarinin parçasıdır. Temelinde neyin ve neye karşı korunması gerektiğine dair net bir tablo vardır.
Ödünleşim · Bedeli: Sonradan kestirme yollara daha az serbestlik. Farklı durum: Hassas veri içermeyen dahili bir araç geliştiriliyorsa konsept yalın kalır, ama boş kalmaz.
Ölçeklenme, erişilebilirlik, işletim
Gerçekte beklenen yükü, tolere edilebilir kesinti süresini ve işletim modelini soruyor; dağıtım, gözlemlenebilirlik (observability), yedekleme ve geri yüklemeyi buradan türetiyoruz.
Ödünleşim · Bedeli: Normal işletimde görünmez kalan yedeklilik ve gözlemlenebilirlik. Farklı durum: Kısa kesintiler kabul edilebilirse yüksek erişilebilirlik yerine daha basit bir işletim.
Build versus Buy
Her bileşenin geliştirilmesi gerekmez. Standart ürünleri, hizmetleri ve özel geliştirmeyi farklılaşma, kullanım ömrü, bağımlılık ve toplam maliyet açısından değerlendiriyoruz.
Ödünleşim · Bedeli: Satın alınan bileşenler tedarikçiye bağımlılık getirir. Farklı durum: Süreç işin özünü oluşturuyorsa özel geliştirme lehine daha fazla gerekçe vardır.
Bakım kolaylığı ve modernizasyon
Mevcut sistemlerde teknik borcu etkisine göre adlandırıyor ve işletimi riske atmayan kademeli bir yol planlıyoruz. Yeni sistemlerde ise değişimin en olası olduğu noktaları değiştirilebilir tutuyoruz.
Ödünleşim · Bedeli: Her borç hemen kapatılmaz. Farklı durum: Bir borç güvenliği veya işletimi aktif olarak tehlikeye atıyorsa önceliklidir.
İlk görüşmeden çalışan sisteme.
Her proje aynı dört adımı izler. Ara sonuçları yalnızca sonda değil, süreç boyunca görür ve değerlendirirsiniz.
- 01
İhtiyacı anlamak, gereksinimleri netleştirmek
İlk görüşmeyi doğrudan yönetimle yaparsınız; projenizi, iş süreçlerinizi ve mevcut sistemlerinizi konuşuruz. Ardından hedefleri ve gereksinimleri yazılı hâle getirir, özel geliştirmenin anlamlı olup olmadığını açıkça söyleriz.
- 02
Çözümü ve mimariyi planlamak
Teknik bir çözüm önerir, kapsamı ve uygulama sırasını belirler, temel kararları gerekçeleriyle birlikte belgeleriz.
- 03
Geliştirmek ve birlikte kontrol etmek
Testler ve kod incelemeleriyle aşama aşama geliştiririz. Ara sonuçları düzenli olarak sunarız; böylece erken değerlendirip öncelikleri değiştirebilirsiniz.
- 04
Yayına almak ve desteğe devam etmek
Yayına alındıktan sonra bakım, güncelleme, izleme ve geliştirmeyi kararlaştırılan kapsamda üstleniriz. Projeye özel kaynak kod ve dokümantasyon size teslim edilir.
Proje sonunda elinizde olanlar.
Gereksinimlerden gerekçelendirilmiş bir hedef mimari
Net sorumluluklar içeren bir sistem ve bağlam haritası
Arayüzler, veriler ve mevcut sistemler için bir entegrasyon konsepti
Bağlamı ve sonuçlarıyla birlikte belgelenmiş mimari kararlar
Ödünleşimleriyle birlikte değerlendirilmiş çözüm alternatifleri
Karşı önlemleri belirlenmiş teknik riskler
Adım adım bir uygulama veya modernizasyon planı
Mimari çıktılar
Yazılım mimarisi ve çözüm tasarımı hakkında sorular
Her proje ayrı bir mimari aşamasına ihtiyaç duyar mı?
Hayır. Derinliği karmaşıklık ve risk belirler: Yönetilebilir bir sistemde mimari, uygulama sürecinde oluşur. Çok sayıda arayüz, hassas veriler veya yüksek erişilebilirlik gereksinimleri söz konusuysa ayrı ve belgelenmiş bir aşama değer.
Monolit mi, mikroservisler mi?
Çoğunlukla net sınırlara sahip modüler bir monolitle başlıyoruz. Yük, erişilebilirlik veya ekip yapısı somut olarak gerektirdiğinde tek tek servisleri ayırıyoruz. Karar gerekçelendirilir ve belgelenir.
Mevcut bir sistemin mimarisini değerlendirebilir misiniz?
Evet. Yapının, verilerin, arayüzlerin ve işletimin envanterini çıkararak başlıyor, riskleri ve teknik borcu etkilerine göre adlandırıyor ve buradan kademeli bir modernizasyon yolu türetiyoruz.
Hangi mimari çıktılar oluşuyor — ve teknolojileri nasıl değerlendiriyorsunuz?
Tipik olarak sistem bağlamına genel bir bakış, bileşenler ve sistemler arasındaki veri akışları, arayüz sözleşmeleri ve bağlam, alternatifler ve sonuçlarıyla Architecture Decision Record'lar (ADR'ler) olarak mimari kararlar. Derinlik ve kapsam projenin riskine göre belirlenir. Teknolojileri bu gereksinimlere göre değerlendiriyoruz, tersi değil: Olgun ve yaygın teknoloji önceliklidir ve her temel seçim gerekçelendirilir.
İlgili konular.
Bu sayfayla bağlantılı rehberler, kararlar, hizmetler ve projeler.
Projenizi konuşalım.
Projenizi kısaca anlatın. İlk görüşmeyi doğrudan yönetimle yaparsınız.
