Hatırlatma: YouTube Kanalıma abone olarak, her hafta eklenen yazılımcılar için programlama ve kariyer video eğitimlerime ulaşabilirsiniz.
Martin Fowler’in eski ve meşhur kitaplarından bir tanesi Patterns of Enterprise Application Architecture. Neredeyse üzerinden 18 yıl geçti bu kitap yazılalı ve yazıldıldığından beri çok şey değişti. Her ne kadar anlatılanlar şu an çoğu gelişimin temellerini oluşturuyor olsa da, bu temellerin yalın hallerininin de kullandığı ve kullanılabileceği yerleri küçümsememek lazım. Kitabın içeriğini ve anlattığı konuları internetten bulmak mümkün. Dolayısıyla burada o kısımlarına çok değinmeyeceğim. Bu arada, bu yazım kitapta şunu anlatıyor, bunu söylüyor şeklinde olmayacak. O zaten kitap özeti olurdu. Ben kendi yorumlarımı yapıyor olacağım.
Kitap ilk olarak daha bütüncül bir yaklaşımla kurumsal yazılım geliştirmede ki sorunları ve çözümleri için hangi pattern’ları kullanabileceğinizi anlatıyor. İlerleyen bölümlerde ise bu pattern’ları detaylamasına kod örnekleri ile inceliyor ve nerede, ne zaman, ve niçin sorularına cevaplar sunuyor. Burada dikkat edilmesi gereken, yazarın da üzerinde ciddiyetle durduğu, sunmuş olduğu çözümlerin direk alınıp kullanması yerine öncelikle sorunu iyice anlamak. Sonrasında ise bu tasarımları kendi çözümlerinize uyarlamak. Yani Martin Fowler, sunmuş olduğu çözümlerin eksik olduğu ve sonucun yazılımcıların uğraştıkları sorunlara göre şekilleneceğini söylüyor. Buna kesinlikle katılıyorum. Aslında bu, uzman yazılımcıların yıllarca acı tatlı tecrübe ettikleri bir gerçek. Her gördüğümüz tavsiyeyi direk ezberlemek ve uygulamak yerine üzerine düşünüp, kendi sorunumuza göre adapte edebilmek gerekiyor.
Bazı patternların eskimiş olduğunu görmek mümkün. Aslında burada ki eskimek ifadesi, biraz daha ön kabüller ve değişen gereksinimlerin insanları daha farklı çözümlere odaklamış olmasından. Aksi halde, hala kullanılmaları mümkün. Tabi neredeyse 20 yıl önceki kurumsal yazımların kapsamları ve karmaşıklığı ile bugünün kurumsal yazılımlar aynı mıdır…? Söylemek zor.
Çok şey değişti. İnternetin ve teknolojinin hayatımızın daha büyük bir parçası haline gelmesinin kurumsal projeler üzerine getirmiş olduğu baskıyı azımsamamak lazım. Ama mesela basit dursa da Transaction Script Pattern hala kullanılabilinir. Özellikle, rapid prototyping yapılan ortamlar da kısa zamanda birşeyler sunabilmek için gayet anlaşılır ve kolay bir çözüm sunuyor. Bu pattern nedir diye sorarsanız, tüm kodunuzu neredeyse bir method içine koymak. Belki sadece bu devasa methodu küçük başka methodlara bölebilirsiniz, ama burada ki tek reusability aynı sınıflar içinde olan bu private methodlar. Dolayısıyla DAL, BLL, Presentation Logic felan hepsi bir method içinde.
Hazır Transaction Script demişken, kitabı okurken ilk başta anlatılan bazı pattern’ların aslında bir pattern olup olmadığı insanın aklına geliyor. Yani Transcation Script gibi Allah ne verdiyse herşeyi bir method içine koymak nasıl bir pattern olsun diye soruyor insan. Ama burada pattern kavramını biraz daha naif anlamak lazım. Öyle kocaman yüce şeyler beklemek yerine, bir yöntem olarak görmek yeterli olacaktır. Yani Transaction Script aslında basit bir kodlama yöntemi sadece. Yazımı kolay, anlaşılması kolay, ama bakımı uzun vadede zor bir çözüm. Ama Domain Model dersek, o zaman yazımı daha zor, anlaşılması daha zor, ama bakımı uzun vadede daha kolay olan bir yöntem görürürüz. Burada farkına varılması gereken şey, mükemmel bir çözümün hemen hemen imkansız olduğu. Mesele içinde bulunan soruna en az zararla çözüm bulmak. Bir kısmı iyileştirirken, her zaman başka kısımları feda etmek zorunda kalacaksınız. Aslında onun için biraz da bu kadar fazla pattern ile uğraşıyoruz.
Bu arada her ne kadar kitap bu ayrımı yapmamış olsa da, bence design pattern ile architectural pattern kavramlarını ayırmak gerekiyor. Bu ikisi arasında benzerlik bulmak mümkün. Dolayısıyla sonu olmayan bir tartışma meydana getirmemek için, bu iki kavramı yeniden tanımlayıp aralarını açacağım. Design patterns daha çok individual components üzerine yoğunlaşmalı. Yani Strategy Pattern gibi yada Decorator direk sınıflar üzerine çalışıyorlar. Ama Architectural Patterns daha çok sistemin genel yapısına odaklanmalı. Yani iç mimari ve binanın inşası gibi. Architectural Pattern’a örnek, MVC, MVVM, Unit of Work, Distributed Patterns, Optimistic ve Pessimistic Offline Locks, Domain Model, Transform View, Template View. Bunun yanında hem design pattern hem de Architectural Pattern olarak gördüğüm diğer patternlardan bazıları Lazy Loading, Front Controller, gibi…
Bu iki pattern arasında ki en büyük farklılaştırıcı etkeni etkiledikleri alan olarak görmek mümkün. Ama bu şekilde bir ayrımı yapmanın eğitim dışında pratik dünyada çok bir faydasını görmeyeceksiniz. Onun için, bu konu hakkında hardcore bir anlayışa ve saplantılara gerek yok. Zaten zamanla bazı isimleri unutuyor olsanız da, yıllarca yapmış olduğunuz tasarımlara dair bilgiler uzun zaman sizinle beraber kalacak.
Peki kitabı tavsiye ediyor muyum? Öncelikle şunları söyleyeyim: 10 yıldan fazladır yazılım mühendisliği yapan birisiyim ve çok farklı mimariler ile çalıştım. Bu kitabı okurken aslında kitaptaki hemen hemen tüm tasarımları kariyerim boyunca kullandığımı farkettim. Bu farkındalık aslında bu kitabın endüstriyi ne kadar etkilemiş olduğunu gösteriyor. Dolayısıyla daha önce yazılım mimarisi üzerine çalışmamış iseniz, o zaman bu kitabı okumak ile başlayabilirsiniz. Hali hazırda tecrübeli olan arkadaşlara çok bir şey katmayabilir. Ama yeni başlayanların bu kitaptan öğreneceği çok şey olduğunu düşünüyorum.