Yazılım Mimarisi mülakat soruları

Adapter deseni, mevcut bir sınıfı yeni bir arayüzle sararak bir arayüz bekleyen kodun uyumsuz bir arayüzü kullanabilmesini sağlayan yapısal tasarım desenidir.

Adapter, genellikle tek bir sınıfı sararak mevcut bir arayüzü istemcilerin zaten beklediği arayüze uydurur. Facade ise karmaşık bir alt sistemi kullanmayı kolaylaştırmak için bir sınıf grubunun üzerinde yeni ve daha basit bir arayüz oluşturur.

Adapter, uyumsuz kodun birlikte çalışabilmesi için arayüzü değiştirir. Decorator ise tam olarak aynı arayüzü korur ve günlükleme ya da önbellekleme gibi davranış eklemek için bir nesneyi sarar.

Ports and adapters olarak da adlandırılan hexagonal architecture aynı fikri bütün bir uygulama düzeyinde uygular. Çekirdek portları arayüz olarak tanımlar; adapter'lar ise bu portlar ile SQL veritabanı veya REST API gibi belirli teknolojiler arasında çeviri yapar.

Aktör modeli, eşzamanlı sistemleri aktörlerden kurar: özel durumu olan ve birbiriyle yalnızca asenkron mesajlar göndererek iletişim kuran bağımsız birimler.

Hayır. Aktör, posta kutusu olan hafif bir nesnedir; bir işletim sistemi thread'i değildir. Bir çalışma ortamı çok sayıda aktörü küçük bir thread havuzu üzerinde zamanlar ve bir aktör yalnızca bir mesajı işlerken bir thread kullanır.

Eşzamanlı olarak değişen birçok bağımsız durum parçası olan sistemler için: sohbet ve mesajlaşma sunucuları, çok oyunculu oyun sunucuları, telekom santralleri, her cihazı bir aktör olarak modelleyen IoT platformları ve alım satım sistemleri. Gözetim mekanizması ve konumdan bağımsız mesajlaşma, onu hataya dayanıklı dağıtık sistemler için de uygun kılar.

Asenkron mesajları takip etmek ve onlarla hata ayıklamak, doğrudan fonksiyon çağrılarına göre daha zordur; yanıt bekleyen bir istek de ek düzenek gerektirir. Teslim garantileri de sınırlıdır: ağ üzerinden bir mesaj kaybolabilir, bu yüzden önemli mesajlar için onay ya da yeniden deneme gerekir.

Backend for frontend, web ya da mobil uygulama gibi her istemci türünün kendi ihtiyaçlarına göre uyarlanmış küçük bir backend aldığı bir mimari desendir.

API gateway, yönlendirme, kimlik doğrulama ve hız sınırlamayı yürüten, tüm istemciler için ortak bir giriş noktasıdır. BFF ise ekranları için veriyi şekillendiren, belirli bir istemciye ait ayrı bir backend'dir ve BFF'ler çoğunlukla bir gateway'in arkasında yer alır.

Web ve mobil uygulamalar gibi birkaç farklı istemcinin aynı servislerden çok farklı veriye ihtiyaç duyduğu ya da ön yüz ekiplerinin API'lerini diğer her ekiple eşgüdüm yapmadan değiştirmek istediği durumlarda yardımcı olur. Basit ihtiyaçları olan tek bir istemci için genellikle tek bir API yeterlidir.

Bazen. GraphQL her istemcinin tam olarak ihtiyaç duyduğu alanları istemesine izin verir ve aynı sorunun büyük kısmını çözer, ancak bazı ekipler oturum yönetimi, güvenlik ya da istemciye özgü mantık için yine de bir BFF ekler.

Builder pattern, karmaşık bir nesneyi ayrı bir builder nesnesiyle, argümanlarla dolu uzun bir constructor yerine adlandırılmış adımlarla adım adım oluşturur.

Bir nesnenin çok sayıda isteğe bağlı parametresi olduğunda, birkaç alan üzerinde doğrulama gerektirdiğinde ya da oluşturulduktan sonra değiştirilemez olması gerektiğinde. Birkaç zorunlu alanı olan nesneler için constructor daha basittir.

Factory hangi nesnenin oluşturulacağına karar verir ve onu tek bir çağrıda döndürür. Builder ise tek bir karmaşık nesneyi oluşturmadan önce birkaç adımda yapılandırmaya odaklanır.

Her metodun nesnenin kendisini döndürdüğü bir API'dir; böylece çağrılar builder.to(...).subject(...).build() gibi okunur bir cümleye zincirlenebilir. Builder'lar genellikle bu şekilde yazılır.

Circuit breaker deseni, arızalı bir bağımlılığa yapılan çağrıları bir süre durdurarak ve zaman aşımlarını beklemek yerine hızlıca hata vererek sistemi korur.

Kapalı, hatalar sayılırken çağrıların normal aktığı anlamına gelir. Açık, çağrıların servise ulaşmadan anında başarısız olduğu anlamına gelir. Yarı açık ise servisin düzelip düzelmediğini kontrol etmek için soğuma süresinden sonra birkaç deneme çağrısına izin verildiği anlamına gelir.

Yeniden deneme, sorun geçici olabilir diye başarısız bir çağrıyı tekrarlar. Circuit breaker ise zorlanan bir servise toparlanma zamanı vermek için tekrarlanan hatalardan sonra çağırmayı bırakır; yeniden denemeler genellikle breaker'ın içinde, denemeler arasında artan bir gecikmeyle çalışır.

Hızlıca başarısız olurlar; genellikle çağıranın ele alabileceği bir hata verirler ya da önbellekteki veri, varsayılan bir değer veya kullanıcı dostu bir mesaj gibi bir yedek yanıt döndürürler. Bu, çağıranı zaman aşımlarında takılıp kalmak yerine duyarlı tutar.

Clean architecture, temel iş kuralları framework'e, veritabanına ya da kullanıcı arayüzüne asla bağımlı olmasın diye yazılımı katmanlara ayırma yöntemidir.

Bağımlılık kuralı, iç bir katmandaki kodun dış bir katmandaki hiçbir şeye bağımlı olmaması gerektiğini söyler. İş kuralları framework ya da veritabanı kodunu içe aktarmaz; bunun yerine dış katmanlar, iç katmanların tanımladığı arayüzlere bağımlıdır.

İkisi de iş mantığını teknik ayrıntılardan yalıtma amacını paylaşır. Hexagonal architecture bunu port ve adaptörlerle çevrili bir çekirdek olarak tarif ederken, clean architecture entity ve use case gibi daha açıkça adlandırılmış katmanlar ekler.

Çoğu zaman evet. Küçük uygulamalarda ya da prototiplerde ek arayüzler ve katmanlar, pek fayda sağlamadan geliştirmeyi yavaşlatabilir. Birçok ekip daha basit başlar ve kod tabanı ile iş kuralları büyüdükçe daha net sınırlar getirir.

Consistent hashing (tutarlı hashleme), anahtarları sunuculara, sunucu eklenip çıkarıldığında yalnızca küçük bir kısmı yer değiştirecek şekilde dağıtır.

Çünkü sunucu sayısını değiştirmek neredeyse her anahtarın sonucunu değiştirir; böylece önbellekteki ya da saklanan verinin neredeyse tamamı birden yanlış sunucuda kalır. Consistent hashing taşınan miktarı küçük bir kısımla sınırlar.

Her fiziksel sunucu için hash halkasındaki ek konumlardır. Sunucu başına çok sayıda kullanmak anahtarların dağılımını dengeler ve daha güçlü sunucuların daha büyük bir pay almasını sağlar.

Cassandra ve DynamoDB gibi dağıtık veritabanlarında hangi düğümlerin hangi veriyi saklayacağına karar vermek için, dağıtık önbelleklerde, CDN'lerde ve bir istemciyi aynı sunucuda tutan yük dengeleyicilerde.

CQRS, veriyi değiştiren kodu (komutlar) veriyi okuyan koddan (sorgular) ayırarak iki ayrı modele bölen bir mimari desendir.

CRUD, veriyi oluşturma, okuma, güncelleme ve silme için tek bir model kullanır. CQRS ise yazmaları ve okumaları ayrı modellere böler; böylece her biri bağımsız olarak optimize edilebilir, bunun bedeli daha fazla karmaşıklıktır.

Hayır. CQRS yalnızca komut ve sorgu modellerinin kodunuzda ayrılmasını gerektirir. Ayrı okuma ve yazma veritabanları kullanmak, okumaları ölçeklemesi ya da veriyi çok farklı şekillerde saklaması gereken sistemler için isteğe bağlı bir adımdır.

CQRS okumayı yazmadan ayırır; event sourcing ise yalnızca mevcut durumu değil, değişikliklerin tam geçmişini bir olay dizisi olarak saklar. Sıklıkla birlikte kullanılırlar ama her biri tek başına da kullanılabilir.