Software Design Patterns — Part 1

By | November 10, 2022

Bu yazımda yazılım dünyasında yer alan çeşitli yazılım mimarilerinden bahsedeceğim. Bildiğiniz üzere uygulamalar yazılmadan önce belirli bir yapı üzerine inşaa edilir, tıpkı bir bina dikilmeden önce çıkarılan yapı planı gibi.

Bir Yazılım Mimarisine Neden İhtiyaç Duyarız?

Eğer uygulama belirli bir yapı üzerine inşaa edilmezse bu uygulamanın bileşenleri arasındaki bağlılık çok yüksek olacaktır. Bu da uygulamada en ufak bir değişiklik yapmak istediğimizde bize çeşitli zorluklar çıkaracaktır.
Mimari yapı bize, “Bu mimari genişleyebiliyor mu?” “Uygulamadan beklediğimiz performans nedir”? “Bu uygulama ihtiyaçlara ne kadar kolay cevap verebiliyor?” gibi soruların cevaplarını bulmamızda yardımcı olur.
Yazılım mimarisini seçerken gereken diğer parametreler ise, seçilen mimari yapının güçlü yanları, zayıf yanları ve günün sonunda uygulamanın ihtiyaçlarını karşılayıp karşılayamamasıdır.

Şimdi yaygın olarak kullanılan mimarilere bir göz atalım.

Katmanlı Mimari (Layered Architecture)

Bu mimari, yazılım mimarileri arasında en çok kullanılan bir diğer deyişle de n — tier mimari desendir. Bir çok Java uygulaması için de sektör tarafından kabul gören ve bir çok yazılım mimarı, tasarımcı ve geliştirici arasında yaygın olarak bilinir ve geleneksel organizasyonel yapıya benzerlik gösterir.
Katmanlı mimaride katmanlar yatay şekildedir ve uygulamada her katmanın spesifik bir görevi vardır. Genel olarak bu mimaride katmanlar şu şekildedir: sunum katmanı (presentation layer), iş katmanı (business layer) ve veritabanı (database layer) katmanıdır. Bu katmanların kısaca görevlerine gelirsek ise; sunum katmanı kullanıcı arayüzüne gelen istekleri karşılar. İş katmanında ise kısaca uygulamanın iş yükleri yazılır. Arayüzden gelen istekler ve veritabanından alınan datalar bu katmanda işlenir. Bu mimaride işler parça parça tamamlanır. Sunum katmanı istemci datasının nasıl alındığını bilmek durumunda değildir, sadece gelen datayı işleyip ekrana yansıtmakla görevlidir. Buna benzer olarak iş katmanının da arayüze yansıtılacak bilgilerin nasıl yansıtılacağını bilmesine gerek yoktur. Sadece gelen datayı alır iş kurallarına göre işler ve arayüze gönderir. Bu mimarinin en güçlü özelliklerinden birisi de bu katmanların ilgilendiği konların birbirlerinden ayrılıyor olmasıdır.

Anahtar Kavramlar

  • Bu mimarinin en önemli kavramlarından birisi her katmanın kapalı olarak işaretlenmesidir. Peki bu ne demek? Bir istek geldiğinde yukarıdan aşağıya doğru tüm katmanlarda hareket eder. Peki neden bu istek direkt olarak arayüzden veritabanı katmanına gitmiyor? Bunun cevabı ise “layers of isolation” olrak bilinen kavramdır. Buradaki her bir katman bir diğeri üzerinde etkisi yoktur. Bu katmanlar birbirileri içerisinde bağımsızlardır ve birbirlerinin nasıl çalıştıkları hakkında çok az bilgiye sahiplerdir.
  • Bazı durumlarda ise ara bir katman olarak servis katmanı konumlandırmak iyi bir fikirdir. Ayrı bir servis katmanı olmadan sunum katmanının, bu servislere erişimini mimari olarak sınırlayamayız. Servis katmanını açık olarak işaretleyerek, gelen isteklerin bu katmanı bypass edip alttaki diğer katmana erişimi sağlanır. Kapalı ve açık katmanlar; tüm katmanlar ve istek akışı arasındaki ilişkiyi tanımlamaya yardımcı olur. Ayrıca, geliştiriciye katmanlar arasındaki erişim kısıtlamaları hakkında gerekli bilgileri de sağlar.

Değerlendirme kısmı okuduğum kitapta 6 ana başlık altında toplanıyor. Bu şekildeki anlatım hoşuma gittiği için ben de aynı yapıda değerlendirme kısmını oluşturdum.
Katmanlı Mimariyi Değerlendirilmesi;

  • Çeviklik: Düşük
    – Değişiklikler, katmanlarda izole bir şekilde yapılmasına rağmen bu mimaride değişiklikler kolay olmaz ve gereğinden fazla zaman harcatabilir. Bu yaşanan sıkıntılar ise monolitik mimarinin doğası gereği ve bileşenlerinin birbirine sıkı bir şekilde bağlı olmasından ortaya çıkmaktadır.
  • Dağıtım Kolaylığı: Düşük
    – Büyük uygulamalar için dağıtım (deployment) bazı durumlarda sıkıntılı olabilmektedir. Bir bileşende yapılacak ufak bir değişiklik, tüm uygulamanın tekrardan dağıtılmasını gerektirebilir. Bu da dağıtımın mesai saatleri dışında veya hafta sonları yapılması yönünde planlanmasına neden olur.
  • Testedilebilirlik: Yüksek
    – Bileşenler bulunduğu spesifik katmana bağlı oldukları için diğer katmanlar mock’lanabilir. Bu da bu mimarinin kolay test edilmesini sağlar.
  • Performans: Düşük
    – Bu mimaride, gelen bir istek tüm katmanlardan geçeceği için verimsizliğe yol açacaktır. Bu da yüksek performanslı uygulamalar için istediğimiz bir durum değildir.
  • Ölçeklenebilirlik: Düşük
    – Monolitik ve katmanların birbirleriyle sıkı şekilde bağlı olmasından dolayı, bu mimaride yazılmış uygulamalar kolay bir şekilde ölçeklendirilemezler. Bu mimaride, her katman ayrı bir şekilde dağıtlır veya tüm uygulamayı birden fazla node’a kopyalanabilir. Fakat bu durumda ölçeklendirme çok masraflı olacaktır.
  • Geliştirme kolaylığı: Yüksek
    – Bu mimari çok iyi bilinen ve uygulanması karışık olmayan bir mimaridir. Bir çok firma uygulamalarını katman katman bölerek geliştireceği için bu mimari iş uygulamaları için biçilmiş kaftandır.
    – Firmaların organizasyonel yapısı ve iletişimi arasındaki bağlantıya ve bu yapıya benzeyen uygulama geliştirme yöntemine Conway’s law denir. Google’dan bu konu hakkında detaylı bilgiler edinebilirsiniz.

Yazımın devamında Olay Dayalı Mimari(Event-Driven Architecture)’den bahsedeceğim.
Kaynakça: Software Architecture Patterns — Mark Richards

Leave a Reply

Your email address will not be published. Required fields are marked *