Martin_Fowler_QCon_2007.jpg

Martin Fowler, yazılım dünyasının önde gelen guru’larından biridir. Geçenlerde bir vesile ile üstadın, “Enterprise Application Architecture” adlı eseri elime geçti. Ben, hem Martin Fowler’ı uzaktan takip eden, hem de Kurumsal Uygulamalara 10 yılını vermiş biri olarak kitaba balıklama daldım tabi. Aşağıda kitapta bulunan ve, genç yazılımcılar için faydalı olabileceğini düşündüğüm, “The Evolution of Layers in Enterprise Application” başlıklı kısa bölümü, naçizane kendi yaptığım çevirisi ile sunuyorum. Yazar bu bölümde yıllar içinde evrimleşen, Kurumsal uygulama geliştirme konusuna kısa bir tarihçe sunarken, katmanlı mimariye nasıl ulaşıldığını özetliyor. Bu serüvenin her kilometresinde, yanlış yapa yapa doğruları öğrenen, ben ve benim gibi diğer yazılım dinazorları için de hoş bir panorama olduğunu düşünüyorum.

KURUMSAL UYGULAMALARDA KATMANLI MİMARİNİN EVRİMİ
Batch sistemlerin erken zamanlarına yetişemeyecek kadar genç olmama rağmen, o zamanlarda insanların katman konusunu önemsediğini sanmıyorum. Bir takım dosyaları (ISAM, VSAM, vb.) yöneten bir program yazarsınız ve bu sizin uygulamanızdır. Katmanlı bir yapı uygulamaya gerek yoktur.
Katman konusu, 90 lı yıllarda istemci-sunucu (client-server) sistemlerin yükselişi ile ortaya çıkmıştır. Bunlar iki katmanlı sistemlerdi: İstemci, kullanıcı arayüzleri ve diğer uygulama kodlarını çalıştırırdı, sunucu da genellikle bir veritabanıydı. Yaygın uygulama geliştirme araçları VB, Powerbuilder ve Delphi idi. Bunlar SQL bağlanabilen arayüz kontrolleri içerdiğinden, veri yoğun uygulama geliştirmeyi oldukça kolaylaştırıyorlardı. Böylece, formlara kontroller sürükleyerek ekranlar oluşturabiliyordunuz ve özellik alanlarını tanımlayarak kontrolleri veritabanına bağlayabiliyordunuz.
Eğer uygulama, genel olarak, ilişkili verileri göstermek ve basit olarak güncellemek ise istemci-sunucu sistemleri iyi iş görüyordu. Problem iş kurallarındaydı: kontroller, hesaplamalar, vs. İnsanlar genellikle bunları istemci tarafında yazarlardı. Fakat bu kötü kodlamaydı ve iş mantığını ekranlara gömmeyi gerektiriyordu. İş kuralları komplike oldukça, bu kod ile çalışmak çok zorlaşıyordu. Dahası, iş mantığını ekranlara gömmek, kodun çoklanmasına sebep oluyordu. Bu da basit değişiklikler için tüm ekranları taramayı gerektiriyordu.
Bir alternatif de iş mantığını, veritabanında sp (stored procedure) lere gömmekti. Ancak sp ler kısıtlı programlama imkanı sunuyordu, bu da yine kötü koda yol açıyordu. Ayrıca, birçok insan, SQL i, gerektiğinde veritabanını değiştirmeye olanak sağlayabilen bir standart olduğu için tercih ediyordu. Gerçekte çok az insanın bunu yapmasına rağmen, birçok insan yüksek taşıma maliyetine katlanmaksızın veritabanı bağımsızlığına sahip olmayı seviyordu.
İstemci-sunucu sistemlerin popülerleştiği sırada, nesne yönelimli (object-oriented) yaklaşım da revaçtaydı. Nesnecilerin iş kuralları problemine verecek bir cevabı vardı: Üç katmanlı bir sistem. Bu yaklaşıma göre; kullanıcı arayüzlerinin bulunduğu bir sunum katmanı, iş kurallarının bulunduğu bir iş katmanı, ve bir veri katmanı vardır. Bu şekilde, girift iş kurallarını arayüzden çıkartıp ayrı bir katmana koyabilirdiniz ve nesneler kullanarak bu katmanı yapılandırabilirdiniz.
Buna karşın, nesne taraftarları bir miktar ileri gitmişti. Gerçekte birçok sistem oldukça sadeydi, ya da en azından öyle başlıyordu. Üç katmanlı yaklaşımın birçok avantajı olmasına rağmen, eğer probleminiz basit ise, istemci-sunucu geliştirme araçları daha cazipti. İstemci-sunucu araçlarını, üç katmanlı mimaride kullanmak ise çok zordu, hatta imkansızdı.
Bence, burada sismik şok, Web’in yükselişi ile geldi. İnsanlar birden, istemci-sunucu uygulamalarını web browser ile kullanmak istediler. Ancak, eğer tüm iş kurallarınız bir istemciye gömülü ise, bu kuralların tamamının bir web arayüzünde tekrar kodlanması gerekir. İyi tasarlanmış bir üç katmanlı uygulamada ise, sadece yeni bir sunum katmanı eklemek işi çözecektir. Dahası, Java ile gördük ki, tam tekmil bir nesne tabanlı geliştirme dili ana yola yerleşmişti bile. Web sayfaları geliştirmek için gerekli araçlar, SQL e daha az bağımlı, üçüncü katmana bağlanmaya daha uygundular.
İnsanlar katman konunu konuştuklarında, genellikle katmanlı mimari ve katlı mimari terimleri üzerinde bir karışıklık olur. İki terim sık olarak eşanlamlı gibi kullanılsa bile, birçok insan kat kavramını fiziksel bir ayrılma ile eşleştirir. İstemci-sunucu sistemleri iki katlı sistemler olarak tanımlanır ve ayrışma fizikseldir: İstemci bir masaüstü bilgisayardır ve sunucu da bir sunucudur. Benim katman kelimesini kullanmam, ayrı katmanları ayrı makinelerde çalıştırmak zorunda olmadığımızı vurgulamak içindir. Ayrıştırılmış bir iş katmanı, istemcide veya sunucuda çalışabilir. Bu durumda iki noktanız ancak üç katmanınız vardır. Yerel bir veritabanı ile, üç katmanı da aynı dizüstü bilgisayarda çalıştırabilirim, ancak yine de üç katmanlı bir yapı vardır.