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

Overcoming Event Size Limits with the Conditional Claim-Check Pattern in Event-Driven Architectures

{:en}In today’s technological age, we typically build our application solutions on event-driven architecture in order…

2 months ago

Securing the Supply Chain of Containerized Applications to Reduce Security Risks (Policy Enforcement-Automated Governance with OPA Gatekeeper and Ratify) – Part 2

{:tr} Makalenin ilk bölümünde, Software Supply Chain güvenliğinin öneminden ve containerized uygulamaların güvenlik risklerini azaltabilmek…

7 months ago

Securing the Supply Chain of Containerized Applications to Reduce Security Risks (Security Scanning, SBOMs, Signing&Verifying Artifacts) – Part 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.…

9 months ago

Delegating Identity & Access Management to Azure AD B2C and Integrating with .NET

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

1 year ago

How to Order Events in Microservices by Using Azure Service Bus (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 years ago

Providing Atomicity for Eventual Consistency with Outbox Pattern in .NET Microservices

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

2 years ago