Strangler Fig Pattern

Bir Dönüşüm Hikayesi

Monolitik uygulamalar tüm bileşenlerinin birbirine sıkıca bağlandığı tek bir projeden oluşur ve bu projeler büyüdükçe bazı sorunları da beraberinde getirir. Bu sorunlardan başlıcaları;

• Projenin hantallaşması
• Bakım maliyetlerinin artması
• Yeni bileşenlerin eklenme süreçlerinin zorlaşması
• Tüm projeyi kapsayan domain bilgisi gerektirmeye başlaması

Bu sorunlardan kurtulmak için genelde proje sahipleri monolitik uygulamaları daha küçük parçalara bölmeyi tercih ederler. “Strangler Fig Pattern” de bu parçaları oluştururken takip edilen tasarım örgülerinden birisidir. Ben de size bu yazıda bu sürecin AgeSA bünyesinde nasıl uygulandığını ve ne gibi sorunlarla karşılaştığımızı anlatacağım.

Öncelikle internette de rahatlıkla kaynaklarını bulabileceğiniz Strangler Fig tasarım örgüsü için en akılda kalıcı ifade “evime incir ağacı diktin” deyimi olabilir. Sebebiyse incir ağacının dikildiği yerdeki yapıları zamanla saracağı ve günün sonunda bu yapıları bir şekilde yıkıp sadece kendisi ayakta kalacağı içindir.

Aynı mantığı kendi monolitik uygulamamız için de kurmaya çalışacağız, gelmek istediğimiz nokta şemada da gözükeceği üzere tek bir monolitik uygulamadan işlevleri ve domainlerine göre ayrılmış daha modern ve küçük uygulamalar çıkarmak. Hedefimiz her adımda tek bir uygulamayı monolitik projeden çıkararak, monolitik projeyi küçültmek ve yeni uygulamalarımızla etrafını sarmak olacak.

Strangler Fig Uygulama Adımları

Monolitik Uygulamaların Analizi

Bir monolitik uygulamanın parçalanma sürecinin ilk ve en önemli adımı analizdir. Neyi parçalayacağını anlamak bunu nasıl yapacağını planlayabilmeni sağlayacaktır.

Dönüşüm

Ayrılan ilk uygulamanın yazılmaya başlandığı ilk andan tüm projenin yeni yapıya taşınma sürecin tamamıdır. Aslında projenin tamamı aynı zamanda dönüşümün kendisidir diyebiliriz.

Beraber Yaşama

Monolitik uygulamanın ayrılan parçaya adapte olması ve ayrılan parçanın monolitik uygulamayla uyumlu çalışabilme sürecidir.

Eleme

Dönüştürülen uygulamanın monolitik uygulamadan doğru şekilde kaldırılması adımıdır. Monolitik uygulamanın küçülmesini sağlayan asıl adımdır. Eleme ne kadar yoğun uygulanabilirse elimizde dönüştürülecek uygulama o kadar küçülecektir.

Biz Nasıl Uyguladık?

Sistem analizini yaparken parçalanacak uygulama bölümlerini DDD (Domain Driven Design) prensiplerine uyarak belirledik. Modülleri belirledikten sonra hangi parçaların hangi modüllere dağıtılacağı ve ortak kullanılan servislerin hangi modüllerin hakimiyetine verileceğini belirledik. Bu şekilde birbirine süreçsel olarak bağlı uygulamaları beraber taşıyarak “Beraber Yaşama” ve “Eleme” adımlarını daha rahat ve pürüzsüz geçirmeyi hedefledik.

Dönüşüme başlarken öncelikle teknoloji seçimi yapılarak ortak kütüphanelerin oluşturulması ve temel mimari prensiplerin belirlenmesi adımları geçildi. Bu şekilde parçalanan uygulamalardaki tüm ortak süreçlerin benzer şekilde tekrarlanmayan maliyetlerle sonuçlandırılması sağlandı. Bir mimaride bulunan tüm katmanlar için yapılan konfigürasyonları kütüphanelerde topladık. Bunu yaparken spring-starter paketlerinin yapılarını referans aldık. Tüm uygulamaları kapsayacak şekilde property’lerle yönetilen starter paketleri oluşturduk. Sol tarafta tüm veri tabanları için datasource ve orm tanımlarının yapıldığı starter paket için kullanılan property örneği bulunmakta. Bu örnekteki gibi uygulamalar crm property’sine sahipse bu veri tabanı için datasource ve orm tanımları yapılmış olacaktır, cid property’sine sahipse bu veri tabanı için datasource ve orm tanımları yapılmış olacaktır.

Dönüşümü yapılan uygulamalar için oluşturulan kütüphanelerin monolitik uygulamadan da kullanılması ve dışarı alınan her projenin kendi istemci kodlarını bir kütüphane olarak sunmasıyla uygulamaların beraber yaşama sorunu aşıldı. Örnek olarak monolitik uygulamadan ayrılan “Sales” modülü için yazılan feign client kodları sales-client olarak modül tarafından paketlenip tekrardan monolitik uygulamaya bağımlılık olarak verildi.

Neler yanlış gitti?

Her ne kadar iyi bir analiz yapılmış olsa da monolitik uygulama içindeki bağımlılıklar tahmin edilenden çok daha girintili bir şekil aldığı için ayrılacak uygulamaların bileşenlerini rahatça dışarı çıkarmakta zorlandık. Çıkarılan parçalar monolitik uygulamada da test eforları yarattığı için aynı işi yapan birden fazla servis parçaları belirmeye başladı.

Parçalamanın en başında kolay çıkarılabilecek, süreç olarak bağımsız parçaları seçerek projeye başladık. Bu ilk adımı atmayı kolaylaştırırken uzun vadede karşımıza çıkabilecek sorunları en baştan görmemize engel oldu.

Mevcut yaşam döngüsü geliştirmeleriyle, yapılması gereken dönüşüm çalışmalarını beraber yönetmekte ve bu sürece karşı oluşturulan direnç karşısında yeni yapıyı dikte etmekte zorlandık.

Sonuç

Sonuç olarak Strangler Fig tasarım örgüsü; eğer bir projeyi parçalamak, küçültmek ve eski projeyi yok etmek niyetindeyseniz takip edebileceğiniz güzel bir alternatif olduğunu belirtmem gerekiyor. Her yolda olduğu gibi burada da karşınıza hesaplayamadığınız durumlar çıkacağını ve her projenin kendi hikayesinin olacağını unutmamak lazım. İyi bir planlama her başarılı projenin anahtarıdır ve bu tasarım örgüsünü de uygulamadan önce gideceğiniz yolu olabilecek en iyi şekilde planlamanızda fayda olacaktır.