Domain Driven Design

Domain-Driven Design, karmaşık yazılım sistemleri geliştirirken karşılaşılan temel problemlere çözümler öneren bir yaklaşım. DDD, yazılım tasarlanırken tüm süreçlerin domain’i esas alarak kurgulanmasını tavsiye ediyor. Konunun ehli Eric Evans “Domain-Driven Design – Tackling Complexity in the Heart of Software” isimli kitabında, kompleks sistemlerde oluşan problemlerin kaynağının çoğunlukla domain’in içinde gizli olduğunu söylüyor. Peki nasıl uygulanıyor bu DDD?

Diyelim ki bir havayolları yazılım sistemi geliştiriyoruz. Biz yazılımcı olarak, ne uçakların hangi koşullarda iniş yaptığını, ne kargoların hangi formüllerle hesaplandığını, ne de havayolu trafiğinin nasıl yönetildiğini biliriz. Bunları bilen kişiye “domain expert”, yani işin ehli diyoruz. Bu kişiler yazılım geliştirmeyi bilseler herşey çok güzel olabilirdi ama, o konuda bize ihtiyaç duyuyorlar. Dolayısıyla bize havayollarını anlatmaları gerekiyor.

Bize tüm işi güzel güzel doğal dille anlatıyorlar, dinliyoruz, not alıyoruz. İhtiyaçlarını belirliyoruz, sistemi modellemeye başlıyoruz. Bir seferde olmuyor ama tabi, tekrar tekrar sorular soruyoruz çünkü bizim işimiz domain’in problemini yazılım dünyasında ifade etmek ve yazılım dünyasında ona çözüm üretmek. Yalnız yazılım dünyasıyla gerçek dünya arasında çok fark var. Biz dünyayı sınıflar, metodlar, algoritmalar olarak görüyoruz, aklımıza polymorphism, inheritence geliyor, pattern’ler geliyor, ama aslında bu gerçek dünya için hiçbir şey ifade etmiyor. Yani ayrı dillerden konuşuyoruz. Bu noktada DDD diyor ki, ilk önce bir ortak dil geliştirmek lazım, bu dile de “Ubiquitous Language” diye komik bir isim verelim. Domain ile ilgili bilgiyi veren kişiler ile ortak bir dil geliştirelim, onlar bize anlatacaklarını hep o dilin kelimeleriyle anlatsınlar, biz de sınıflarımıza, metodlarımıza o dilin kavramlarını kullanarak isim verelim. En azından aşağı yukarı aynı şeylerden bahsediyor hale gelelim.

Dil konusundan sonra, biraz da yazılımı modelleme esnasında katmanlı bir yapı oluşturmaktan bahsediyoruz. Domain Driven Design, “Presentation Layer”, “Application Layer”, “Domain Layer” ve “Infrastructure Layer” olarak dört katman üzerinde sistemi kurgulamayı öneriyor. Burada Domain katmanı sistemin temelini oluşturuyor ve tüm domain nesneleri, iş kuralları (business rules) gibi domain’le alakalı kavramları burada tanımlıyoruz. Son olarak domain katmanını mümkün olduğunca diğer katmanlardan izole etmeye, yani bağlılığını azaltmaya çalışıyoruz. Basitçe ifade etmek gerekirse, domain katmanında işi tanımlıyor ve diğer katmanlları domain katmanına servis edecek şekilde tasarlıyoruz. DDD, katmanlı yapıyı bu şekilde tasarlayabilmemiz için bazı tasarım blokları öneriyor. Eric Evans yukarıda bahsedilen kitabında bu blokları detaylı olarak anlatıyor.

Biliyoruz ki “Refactoring” karmaşık sistemler için çok baş ağrıtan bir konu. Kompleks bir sistemi tam olarak modellemek oldukça zordur, mutlaka açıkta kalan, net olmayan konseptler olacaktır. Domain Driven Design bu konuda bazı öneriler sunuyor. DDD’ye göre, refactoring sürekli devam etmeli ve domain’in soyut olarak kalmış tüm kavramları aranarak bunlar somut olarak sistemde ifade edilmeli. Yani anlaşılmamış veya belirsizlik içeren herşey açıklığa kavuşmalı. Bunu sağlamada yardımcı olması amacıyla üç yöntem öneriliyor (Constraint, Process, Specification). Aşağıda bağlantısını verdiğim araştırma makalemden bu yöntemler hakkında detaylı bilgi edinebilirsiniz.

DDD’nin son olarak dikkat çektiği konu, model bütünlüğünü sağlamak. Büyük sistemlerin modelleri de büyük olur ve bir noktadan sonra modelin bütününe yukarıdan bakmak pek mümkün olmayabilir. Modelin alt modelleri, servisleri, modülleri gibi tüm alt elemanları tek başlarına bile oldukça kapsamlıyken, modelin bütünlüğünü sağlamak ve sürdürmek başlı başına bir mesele olacaktır. DDD, bir modelin alt elemanlarını gruplayıp, her alt modelin fonksiyonalitesine ve karakteristiğine göre onları verimli şekilde organize etmek konusunda yardımcı olacak bazı yöntemler ve pattern’ler tanımlıyor. Bu pattern’ler de detaylı olarak makaledeki kaynaklardan incelenebilir.

Eric Evans bir röportajında diyor ki Domain-Driven Design yazılım dünyasının popüler konularından birisi oldu ve kapsamlı yazılım projelerinde kullanılıp faydası görüldükçe yaygınlaşacak, ilgili konseptleri daha da geliştirilecek. Buna ek olarak, “Görmemişin DDD’si olmuş, tutup projesine takmış” durumuna da düşmeyin diyor. DDD’yi heryerde kullanmıyoruz, yalnızca gerektiği yerde gerektiği oranda uygulayıp, gerekmediği yerde unutuyoruz. Çünkü Domain-Driven Design,  olduğu gibi alıp projenizi üstüne oturttuğunuz bir kalıp değil, bazı yöntemler öneren teorik bir yaklaşım.

DDD ile ilgili yazdığım araştırma makalesi : https://alifindik.wordpress.com/wp-content/uploads/2011/06/domain-driven-design-findik_ali.pdf

The Origins of Pattern Theory by Christopher Alexander – OOPSLA Speech

Cristopher Alexander, mimari dünyasındaki pattern dilinin mucidi. Dünyada şimdiye kadar yapılmış ve genel olarak “güzel” sıfatını edinebilmiş tüm yapıların ortak özelliklerini inceleyip, bir yapıyı “güzel” hale getirecek bazı kurallar havuzu geliştirme fikrini ortaya atıyor. Bunu duyan yazılımcılar, “sonuçta biz de yapı inşa ediyoruz,  benzer pattern’ler kullansak uygulamalarımız daha güzel olur mu?” diyorlar. Bunun üzerine Alexander, 1996’da California’da yazılımcılara bir konferans veriyor ve bununla ilgili görüşlerini açıkça ifade ediyor.

Konuşmaya mimari dünyasındaki son durumdan ve o güne kadar yaptığı çalışmaların beklediği oranda bir fayda sağlayamamış olmadığından ötürü duyduğu mutsuzluğu dile getirerek başlıyor. Ona göre mimarlığın temel amacı, “yaşayan yapılar” üretmek olmalı. Dünyadaki mimari yapılanmanın “cansız” olduğunu açıklıyor ve günden güne daha da kötüye gitmesinden kaynaklanan ümitsizliğinden bahsediyor. “Pattern” teorilerini ortaya atmasının ve bununla ilgili çalışmalar yapmasının temel nedeninin, yaşayan yapılar üretmek için bazı “genel doğru”lar geliştirmek olduğunu söylüyor.

Mimarideki şablon kavramının yazılımcıların şablonlarından temel farkının, üretilme amacı olduğunu ve mimaride şablonların üretilmesinde “göze hitap etme, güzellik” kavramının temel unsur olduğunu ifade ediyor. “Tarihteki tüm güzel olarak nitelendirilmiş yapıların ortak özellikleri nelerdir, bu özellikler yeni yapılara uygulanırsa ne gibi güzellikler ortaya çıkabilir?” sorusunun cevabından türeyen mimari şablonlarının, beklediği güzelliği beklediği oranda oluşturamadığını da üzüntüyle dile getiriyor. Yazılımdaki şablonların üretilme amacının ise kullanım kolaylığı, sorunlara ortak çözüm üretme gibi kavramlardan doğduğunu söylüyor. Yazılımdaki şablonlar yazılımın “göze güzel görünür” olmasını değil, ideal çalışmasını amaçlıyor. Bu farka katılıyorum, fakat yazılım dünyasında bu “ideal çalışma” talebinin oluşma nedeninin, dünya üzerindeki “çirkin” yapıların yaratılmış olma nedeniyle aynı olduğunu düşünüyorum. Büyük yazılım projelerinde karmaşık sorunlara çözüm üreten şablonlar, karmaşık problemlere sahip olduğumuz, kalabalık dünya için geçerli. Tüm mimarlar dünyadaki çirkin yapıları düzeltmeye kalksa, çok küçük bir oranını bile düzeltemeyeceklerini söylüyor Alexander. Yazılımda da şablonlarla sadece geleceğin ruhsuz yazılımlarının oluşturacağı karmaşık dünyayı daha kolay ve ideal yöntemlerle baştan yaratıyoruz. Dünya bu kadar kompleks bir yer olmak zorunda mıdır? Şu an erişebildiğimiz bilginin ne kadarına ihtiyacımız var?

Alexander’a göre doğadaki düzeni sağlamak için, doğanın dinamiğine uygun yapılar geliştirmek gerekli. Kendi kendini besleyen canlı sistemlerin sürekliliği ve güzelliği getireceğini düşünüyor. Mimari dünyasında ikinci dünya savaşı dönemlerinden beri canlı yapıların geliştirilmediğinden bahsediyor. Bu canlılık konusunda ilginç bir noktaya değiniyor ve, bilişim teknolojilerinin canlı sistemler üretme yöntemini baz alarak geliştiğini söyleyerek, bilişim ve yazılım dünyasından yardım istiyor. Yazılımın geleceği belirleyecek en önemli gelişim alanlarından biri olduğunu öngörüyor ve yazılımdaki bu “yenileyici” sürecin mimari dünyasına da adapte edilmesi gerektiğini, dünyanın ancak bu şekilde daha güzel bir yer olabileceğini söylüyor. Güncel örnek verelim, para kazanmak amacıyla bir web sitesi yapacaksanız, içeriği kendiniz gireceğiniz bir sitedense, insanların besleyeceği bir siteyi tercih edersiniz. Tüm büyük başarılı(!) örnekler bu şekilde çalışmıyor mu? Eğer Alexander’ın bahsettiği canlı sistem kavramı bu ise, bunun yarattığı ve yaratacağı bilişim dünyasının, mimari dünyanın şu an gelmiş olduğu durumdan farklı olacağını sanmıyorum. Doğadaki canlılık, Alexander’ın en başta yola çıktığı “moral” noktasından başlamalı. Bir ormandan bir fotoğraf karesi aldığınızı düşünün, bu karede bir ağacın yapısını, üzerindeki delikte yaşayan hayvanı, dalına yapılmış olan kuş yuvasını, yanından geçen dereyi ve tüm canlılığın uyumunu düşünün. Doğanın ne bir şablon, ne de bir yöntem kullanarak bunu kurguladığını düşünmüyorum. Aynı Alexander’ın dediği gibi, içinde yaşayacak olan kişiler yaşayacakları yerleri bizzat oluşturursalar, doğanın bize zaten sağladığı canlılığı simüle etmek zorunda kalmayız. Bilişim dünyasına dönelim, bilgisayar teknolojisi, önceden yapılan işleri kullanarak daha büyük işler yapan sistemler geliştirmek üzerine kuruldu ve ilerliyor.  Robotlar yaşamımıza girdi, girecek, eğer Turing yanılmış ise belki bir gün akıllı robot üreten robotlar da üretilecek. Alexander’ın “Generative Process” olarak nitelendirdiği ve medet umduğu yazılım dünyasının gelişimini kurgulayan bu kavram, getireceklerinden fazla götürecek gibi geliyor bana. Ya da bilimkurgulardan çok etkileniyorum belki de. Bana kalsa, dünyayı emanet edeceğim son meslek grubu bilgisayarcılar olurdu herhalde.

Konferansın metni : http://www.patternlanguage.com/archive/ieee/ieeetext.htm