Domain Driven Desig Temelleri - Baslangic

Giriş

Bir yazilim gelistirmek istediğimizde aslinda birilerinin karsilastigi bazi problemleri kolay ve verimli bir sistem inşa ederek çözüm bulmak isteriz. Karsilastigimiz domain uzmani (expert) bize bir sorunundan, probleminden bahseder. Gerçek hayatta bu sorun oldukca karmasik dir. Genelde yapılan problemin verisi üzerinden genel bir çözüm bulmak olursa, çok fazla gereksiz karmasiklik ile yüzleşiriz ve zaman içinde çözüm bulmak için bize verilen problem, ilk versiyon ciktiktiktan sonra çözülmüş olsa da, yeni istekler, bakim ve bir takim farkli ihtiyaclar yüzünden icinden cikilmaz bir hal alir.

DDD Bize Ne Katıyor

DDD, zor yazılım sorunlarının ve hatta iş sorunlarının üstesinden gelmemize yardımcı olacak ilkeler ve modeller sağlar. Bunlar, çok karmaşık sorunları çözmek için başarıyla kullanılan kalıplardır (Patern). DDD, testlerle kolay anlayabileceğimiz ve doğrulayabileceğimiz koddaki sorunlarin temiz bir temsilini sağlar. Bu sayede temiz, okunabilir, test edilebilir ve geliştirilebilir yazilimlar üretmemiz için bize rehberlik eder.

Test Edilebilirlik

Yazdığımız kodun test edilebilir olması çok önemlidir. Cünkü gerçek hayatta karşılaşılan bir karmasik sorunu çözmek, doğal olarak kodumuzda cok fazla bug yaratacaktir. Bu buglari her seferinde bu karmasik sistemi ayagi kaldirarak manuel olarak test edip bulmak cok zaman alici olacaktir. Aslinda kod yazarken yapmamiz gereken tamamen test edilebilirlik ve okunabilirlik üzerinden gelecekteki kendimize yada is arkadasimiza bir takim bilgiler iletmekten baska birsey degildir. Bilgisayar, sunucu her nerede calisiyorsa kodumuz, sistem icin aslinda herseyin tek bir fonksiyonda olup olmamasi farketmez. Fakat biz bu kodu kontrol etmekte ve gelistirmekte cok zorluk yasariz. Bu sebepten dolayi pek cok yazilim gelistirme ilkesi gelistirilmistir (SOLID, DRY gibi). Iste DDD bu prensipleri de kullanip, karmasik is akislarini kolayca modelleyebildigimiz bir yazilim gelistirme prensipleri dizisidir.

Asil Amaç Problem Çözmek Kod Yazmak Değil

Kodlamayi cok seven geliştiriciler olarak, yeni bir projeye başlarken, hemen kod yazmaya başlamak için can atariz . Ancak müşterinin ihtiyaçlarını gerçekten anlamadan yazılım geliştirmek cok sorumludur. DDD, yalnızca müşterinizin ne istediğini anlamaya değil, aynı zamanda bir proje aracılığıyla onlarla tam ortak olarak çalışmaya da önem verir. Nihai amaç kod yazmak, hatta yazılım geliştirmek değil, sorunları çözmektir. Müşterilerimiz yazılım geliştirmekle değil, islerinde başarılı olmakla ilgilidirler. Yazılım, bu amaç için aslinda daha verimli bir araçtan başka bir sey degildir.

Temel Olarak DDD yi Anlamak

Domain Uzmaninin Önemi

Amacimiz kompleks sorunları çözmek oldugu icin DDD yi kullanmak istiyoruz fakat DDD nin kendisi de aslinda yeterince karmasiktir. Bu nedenle biraz tepeden bakmak faydali olabilir. Öncelikle DDD bizi domain expert ile daha fazla iletisim kurmaya teşvik eder. Aslinda projenin başında bu domain expert ile iyi bir iletisim kurup onu projeye dahil etmek çok önemlidir. Bu kisiler analistler ya da satiscilar ürün uzmanlari gibi yazilim sürecerinden kodlamadan cok haberi olmayan insanlar olabilir. Fakat aslında kendilerinin kafalarinda yazmayi istediginiz yazilim yazili haldedir. Iste DDD ile bu uzmanin kafasındakileri koda dökme iddiası dayiz. Bu amaçla iletisime gectiginiz bu uzman ile ilk başta biraz konuşup sistemi anladığını zannedip ondan sonra proje icinde kendi konusma dilimizi ve terimlerimizi olusturup gelistirmeye basladik. Bazi temel kavramlara hatta kendi koyduğumuz isimler ile kendi aramızdaki iletisimimizi arttırdık. Iste bu asamada proje domain uzmanından uzaklaşıyor ve yeni gelen bir istek veya bug bildiriminde kendi içimizde ki iletisimimiz bile sekteye uğrayabilir. DDD bize mümkün oldugu kadar cok bu domain expert ile iletişim halinde olmamizi salik veriyor. Odaklanmak ve Böl Yönet! DDD deki diğer bir temel kavram da aynı anda tek bir alt alana odaklanmaktır. Domain uzmanimiz ilk başta yapmak istediğimiz uygulama icin en üst seviyede kafasindaki parçaları bizimle paylaşır. Bir e-ticaret uygulamasi gelistirmek istediginiz farz edelim. Ürün satin alma, depolama, ödeme, pazarlama vb. pekcok hayalinden bize bahseder. Bu görevlerin her biri kendi içinde kendi özel görevleri, terminolojisi ve zorluklarıyla dolu karmaşık alt etki alanlarina sahiptirler ve aralarında yalnızca minimum etkileşime sahip olabilir. Birçok uygulama aynı anda çok fazla şey yapmaya çalışır, ardından ek davranış eklemek giderek daha zor ve pahalı hale gelir. DDD ile bölerek bu karmasikligin üstesinden gelmek daha kolay olacaktır. Problemi ayrı alt alanlara ayırarak, her problem bağımsız olarak çözülebilir, bu da problemin çözülmesini çok daha kolay hale getirir.

Yazılımda Modelleme Sorunlari

Önemli konular:

Problem Domain i anlamak: Üzerinde çalıştığınız yazılımın çözmeye çalıştığı belirli sorun. (The specific problem the software you're working on is trying to solve.)
Core Domain: Müşterinin işi için temel farklılaştırıcı -- iyi yapmaları gereken ve dış kaynak kullanamayacakları bir şey. (The key differentiator for the customer's business -- something they must do well and cannot outsource.)
Sub Domains: Yazılımınızın desteklemesi veya etkileşimde bulunması gereken ayrı uygulamalar ve ya özellikler. (Separate applications or features your software must support or interact with)
Bounded Context: Sistemin diğer bölümlerinden ayıran açık sınırları olan belirli bir sorumluluk. (A specific responsibility, with explicit boundaries that separate it from other parts of the system.)
Context Mapping: Sınırlı bağlamı ve bunların birbirleriyle olan ilişkilerini belirleme süreci (The process of identifying bounded context and their relationships to one another)
Shared Kernel: Modelin bir kısmı, işbirliği olmadan değiştirmeyi kabul eden iki veya daha fazla ekip tarafından paylaşılıyor. (Part of the model is shared by two or more teams, who agree not to change it without collaboration.)
Ubiquitous Language: Programcıların ve alan uzmanlarının belirli bir alt sistemi tartışmak için kullandıkları bir alan modelinden terimleri kullanan dil. (The language using terms from a domain model that programmers and domain expüerts use to discuss that particular sub-system)

Namespaces

Kodda ad alanları, hangi sınırlı bağlamda çalıştığınızı hızlı bir şekilde belirlemenize yardımcı olur.

Modelimizi geliştirirken Bounded Context’imizi gelistirmeyi ihmal etmemeniz çok önemli çünkü Eğer Modelinizin etrafına sınırlar koymazsak, sonunda uymadıkları yerlerde kullanılır. Uygulamanın bir bölümünde anlam ifade eden kavramlar, aynı isme sahip olsalar ve bazen de kelimenin tam anlamıyla aynı şeyi ifade etseler bile diğerinde anlam ifade etmeyebilir.

Örneğin, bu sistemin randevu planlama bölümünü oluştururken, müşteriler hakkında bazı çok temel bilgileri bilmemiz gerekiyordu. Ancak randevu planlaması bağlamında, bunlar adlarının ötesinde çok az davranışa sahip çok basit kavramlardır. Bununla birlikte, faturalandırma bağlamında, müşteriler için iletişim ve ödeme bilgilerini dahil etmek isteriz, ancak bu, randevu planlama bağlamında önemsemediğimiz bilgilerdir.Aynı istemci modelini birden çok yerde yeniden kullanmaya çalışırken, sistemimizde tutarsız davranışlara neden olabilir.

Aslında Evans, sınırlı bağlamların, her bağlama kendi ekibini, kod tabanını ve veritabanı şemasını vererek ayrılmalarını korumasını önerir.