Yazılım tasarım desenleri ve mimari kararlar: uygulama rehberi

Tasarım deseni ve mimari karar: farklı ölçekler

Tasarım deseni, yazılımda tekrar eden bir tasarım sorununa verilmiş, adı konmuş ve denenmiş bir çözüm şablonudur. Nesneler nasıl oluşturulur, nasıl bir araya gelir, birbirleriyle nasıl konuşur gibi sorular sınıf ve modül ölçeğinde cevaplanır. Mimari karar ise daha büyük ölçekte verilir: sistem tek parça mı olacak yoksa servislere mi bölünecek, veri nerede tutulacak, hangi bileşen hangisine bağımlı olacak.

İkisi birbirine bağlıdır. Mimari stil, kod seviyesinde hangi desenlerin doğal olacağını belirler; kod seviyesindeki desen tercihleri ise mimarinin sürdürülebilirliğini etkiler. Bu yüzden yazılım tasarımını iyi uygulayan biri hem küçük ölçekteki kalıpları hem de büyük ölçekteki dengeleri birlikte düşünür.

Desenleri uygulamadan önce: prensipler

Desenler tek başına öğrenilince kolayca aşırı kullanılır. Önce tasarımı yönlendiren prensipler oturmalıdır. SOLID adıyla bilinen prensipler bunların başında gelir: bir sınıfın tek bir değişim nedeni olması, genişlemeye açık ama değişikliğe kapalı olma, alt tiplerin üst tiplerin yerine geçebilmesi, geniş arayüzler yerine amaca özel arayüzler ve soyutlamalara bağımlılık.

Bu prensipleri bir ölçüt gibi düşünün. Yeni bir özellik eklerken birçok yere dokunmak zorunda kalıyorsanız, bir sınıfı test etmek için yarım sistemi ayağa kaldırıyorsanız ya da küçük bir değişiklik beklenmedik yerleri bozuyorsa prensiplerden biri çiğnenmiş olabilir. Desen, bu sorunu çözmek için başvurulan araçlardan biridir; amaç değil.

Desen aileleri ve ne zaman kullanılır

Klasik desen kataloğu aileler halinde düzenlenir.

Yaratıcı desenler nesne oluşturmayı yönetir. Factory, nesnenin hangi sınıftan üretileceği kararını çağıran koddan ayırır; Builder, çok parametreli nesneleri adım adım kurar. Yeni bir tür eklendiğinde çağıran kodun değişmesini istemiyorsanız yararlıdır.

Yapısal desenler nesnelerin nasıl birleşeceğini düzenler. Adapter, uyumsuz bir arayüzü beklenen arayüze çevirir; Decorator, bir nesneye davranışı sarmalayarak ekler; Facade, karmaşık bir alt sistemi tek bir basit girişe indirger. Dış sistemlerle entegrasyonda sıkça karşılaşılır.

Davranışsal desenler nesneler arası sorumluluk dağılımını ve iletişimi kurar. Strategy, değişen algoritmayı değiştirilebilir parçaya ayırır; Observer, bir olay olduğunda ilgilileri haberdar eder; Command, bir isteği nesne haline getirir. Koşul zincirleriyle dolan kodu sadeleştirmek için sık kullanılırlar.

Bir desen seçerken önce yaşadığınız sorunu adlandırın. Sorun adı yoksa desen çoğu zaman gereksiz karmaşıklıktır.

Mimari kararlar nasıl verilir ve kaydedilir?

Mimari kararların çoğu geri dönüşü pahalı seçimlerdir; bu yüzden tek bir doğruyu aramak yerine kalite niteliklerini dengelemek gerekir. Performans, değiştirilebilirlik, güvenlik, işletme kolaylığı ve ekip yapısı çoğu zaman birbiriyle çelişir. Karar verirken önce hangi niteliğin bu sistem için öncelikli olduğu yazılır, sonra seçenekler bu ölçüte göre karşılaştırılır.

Kararın gerekçesini kaybetmemek için ADR, yani mimari karar kaydı yazılır. İyi bir kayıt kısa bir belgedir ve genellikle şu bölümleri içerir: • Bağlam: karar neden gündeme geldi, hangi kısıtlar var. • Karar: neye karar verildi. • Seçenekler: değerlendirilen alternatifler ve neden elendikleri. • Sonuçlar: kararın getirdiği kazanım ve kabul edilen ödünler. • Durum: önerildi, kabul edildi ya da yerine yenisi geçti.

Kayıtlar kod deposunda tutulursa aylar sonra gelen bir ekip üyesi neden bu yapıyı seçtiğinizi sorgulamadan anlayabilir.

Örnek senaryo: ödeme sağlayıcısı entegrasyonu

Örneğin bir e-ticaret uygulamasında iki farklı ödeme sağlayıcısı destekleniyor ve üçüncüsü ekleniyor. Her sağlayıcı için çağıran kodda ayrı koşullar birikmiş durumda. Çözüm olarak ortak bir ödeme arayüzü tanımlanır; her sağlayıcı kendi sınıfında bu arayüzü uygular (Strategy), hangisinin kullanılacağı bir üretici sınıfta seçilir (Factory) ve sağlayıcıların farklı yanıt biçimleri bir dönüştürücüyle ortak modele çevrilir (Adapter).

Aynı çalışmada mimari soru da vardır: ödeme mantığı ana uygulamanın içinde mi kalacak, ayrı bir servis mi olacak? Bu kararın gerekçesi, seçilen alternatifler ve kabul edilen ödünler bir ADR olarak yazılır. Böylece hem kod hem karar izlenebilir kalır.

Sık yapılan hatalar ve değerlendirme

En sık hata, deseni sorundan önce seçmektir. Her yere Singleton, her soyutlamaya fabrika koyan bir kod tabanı, desen kullandığı halde okunması zor olandır. İkinci hata, mimari kararı tartışma toplantısında sözlü bırakmaktır; kayıt tutulmayan karar bir süre sonra efsaneye dönüşür. Üçüncüsü, mimariyi bir kez çizip bir daha gözden geçirmemektir.

Mevcut bir sistemi değerlendirirken bağımlılık yönlerine, değişiklik maliyetine ve test edilebilirliğe bakılır. Refactor, davranışı değiştirmeden yapıyı iyileştirme çalışmasıdır ve ancak testlerin güvencesi varken yapılmalıdır. Küçük, geri alınabilir adımlarla ilerlemek büyük yeniden yazım projelerinden genellikle daha güvenlidir.

Pratik bir gözden geçirme sorusu: bu kod bir sonraki değişiklikte kaç yere dokunmayı gerektiriyor? Cevap çoksa önce sorunu adlandırın, sonra deseni değil en küçük yeniden düzenlemeyi deneyin.

Öğrenme yolu ve Mindset programları

Başlangıçta SOLID prensiplerini kendi kodunuzda gözlemleyin, ardından her desen ailesinden birer örneği küçük bir uygulamada kurun. İleri aşamada mimari stilleri karşılaştırmayı, karar kaydı yazmayı ve mevcut sistemleri değerlendirmeyi çalışın.

Mindset'in Yazılım Mimarisi ve Tasarım Desenleri programının modülleri bu sırayı izler: Mimari Düşünce ve Karar Alma, SOLID ve Tasarım Prensipleri, Yaratıcı, Yapısal ve Davranışsal Tasarım Desenleri, Mimari Stiller, Mimari Değerlendirme ve Refactor ile Gerçek Senaryo: Kurumsal Mimari Tasarımı. Yazılım Mimarisi Kararları ve ADR Dokümantasyonu programı ise karar kaydının yapısını ve yaşam döngüsünü ele alır.