Merhaba arkadaşlar.

Bu makalemde sizlere distributed architecture design pattern’leri arasında bulunan Remote Facade pattern’i hakkındaki bilgilerimi aktarmaya çalışacağım.

Bu pattern’i anladığımızda her ne kadar basit ve kolay gelecek olsa da, aslında yaptığı iş ve sağlayacağı fayda açısından asla küçümsememeliyiz. Günümüzde mobil uygulamalar sayesinde RESTful tabanlı mimarilerin git gide popülerleşmesi ile birlikte, yeni geliştirilen ve mevcut sistemler yavaş yavaş servis yönelimli mimarilere kaymaktadır. Bu mimarilerin getirdiği faydaların yanı sıra, “latency” ve “network yavaşlığı” gibi problemleri de beraberinde getirmektedir. Helede bu servislerin implementasyonu sırasında yanlış kararlar verilip, her bir işlem için sürekli ilgili servis call ediliyorsa. Bu gibi durumlarda fazlasıyla servis çağrılarında bulunulacağı için, ilgili servis çağrısı yapan uygulamanın hız performansı hemde çağrılan servisin yüksek concurrent işlem anında ölçeklenebilirliğini sağlamak zamanla imkansız bir hale gelecektir. Peki bu gibi durumlarda neler yapmalıyız?, nelere dikkat etmeliyiz kısmına bir bakalım.

Nedir Remote Facade?

Martin Fowler bu pattern için kitabında derki;

“Provides a coarse-grained facade on fine-grained objects to improve efficiency over a network”

Yani Remote Facade’ın özünde yaptığı iş, network verimliliğini arttırmak için birden fazla veriyi servis üzerinden tek tek çekmek yerine bunu bir nesne üzerinde bir kere çekmektir. Bu sayede hem client tarafında performans artışı sağlamış hemde servis tarafında transaction sayısını azaltacağımız için verimliliğinide sağlamış oluruz.

Remote Facade pattern’inin bir başka faydası ise bize, karmaşık business işlemlerininde kolaylıkla tek bir servis çağrısı ile handle edebilmemizi sağlamasıdır.

Nasıl Kullanılır?

Kullanımı yukarıdaki diyagramda görüldüğü gibi aslında oldukça basit örneklemiş Martin Fowler. Buradaki tasarımda görüldüğü gibi Address Facade tasarımı, Address Domain Model‘inden “GetStreet”, “GetZip”, “GetCity” method’larına tek tek servis çağrısı bulunulması yerine, Address Facade üzerinden “GetAddressData” method’u ile bu üç method sonucuna tek bir servis çağrısı aracılığı ile erişilebilinmesini sağlamaktadır. Bu sayede hem network üzerindeki yoğun trafik oranı hemde sunucu tarafındaki serialization maliyeti düşürülmüş olacaktır.

Buradaki Address Facade modeli aklımızı Data Transfer Object (DTO) modeli ile belki karıştırabilir. DTO modeli de içerisinde ortak olan business’ları encapsule ederek, katmanlar arası data geçirebilmektedir. Fakat DTO içerisinde herhangi bir setter method barındırmamaktadır. Remote Facade deseninde ise setter işlemler de dahil olmak üzere, aynı business’lar için bir arada yapılabilmektedir.

Peki derseniz GOF pattern’leri arasında bulunan Facade pattern’i ile arasındaki fark nedir derseniz? Ozaman şöyle diyelim:

  • Facade pattern’i kompleks olan methodların sadeleştirilmesi ile ilgilenirken, Remote Facade pattern’i ise: tam olarak ortak kullanılan birkaç methodu birleştirerek, network trafiğini ve latency oranını azaltmak ile ilgilenmektedir.

Sonuç olarak Remote Facade deseni servis yönelimli mimariler üzerinde network verimliliğimizi daha iyi ölçekleyebilmek adına, birkaç ortak method’u tek bir servis çağrısı aracılığı ile gerçekleştirebilmemizi sağlamaktadır.

Umarım faydalı bir yazı olmuştur. Bir başka yazımda görüşmek dileğiyle.

 

Gökhan Gökalp

Recent Posts

Containerized Uygulamaların Supply Chain’ini Güvence Altına Alarak Güvenlik Risklerini Azaltma (Güvenlik Taraması, SBOM’lar, Artifact’lerin İmzalanması ve Doğrulanması) – Bölüm 1

{:tr}Bildiğimiz gibi modern yazılım geliştirme ortamında containerization'ın benimsenmesi, uygulamaların oluşturulma ve dağıtılma şekillerini oldukça değiştirdi.…

8 ay ago

Identity & Access Management İşlemlerini Azure AD B2C ile .NET Ortamında Gerçekleştirmek

{:tr}Bildiğimiz gibi bir ürün geliştirirken olabildiğince farklı cloud çözümlerinden faydalanmak, harcanacak zaman ve karmaşıklığın yanı…

12 ay ago

Azure Service Bus Kullanarak Microservice’lerde Event’ler Nasıl Sıralanır (FIFO Consumers)

{:tr}Bazen bazı senaryolar vardır karmaşıklığını veya eksi yanlarını bildiğimiz halde implemente etmekten kaçamadığımız veya implemente…

2 yıl ago

.NET Microservice’lerinde Outbox Pattern’ı ile Eventual Consistency için Atomicity Sağlama

{:tr}Bildiğimiz gibi microservice architecture'ına adapte olmanın bir çok artı noktası olduğu gibi, maalesef getirdiği bazı…

2 yıl ago

Dapr ve .NET Kullanarak Minimum Efor ile Microservice’ler Geliştirmek – 02 (Azure Container Apps)

{:tr}Bir önceki makale serisinde Dapr projesinden ve faydalarından bahsedip, local ortamda self-hosted mode olarak .NET…

2 yıl ago