Domain Driven Design Kimdir?
Söyleşimizin ilk bölümünde Domain Driven Design yani nam-ı diğer DDD ile problem çözerken hangi stratejilerden yararlandığı hakkında konuşuyoruz.
Teknolojinin dili olsa da konuşsa dediğiniz oldu mu hiç? Bugün sizlerle birlikte farklı bir şey deneyeceğiz. Teknolojiye konuşması için gerekli olan meziyetleri vererek onunla karşımda bir insan varmışcasına bir söyleşi yapmayı deneyeceğim. Yani DDD’nin bize biraz kendisinden bahsetmesini isteyeceğiz.
Bu söyleşinin sonunda aşağıdaki soruların hepsine cevap bulmuş olacağız.
- “Ubiquitous Language” nedir? Neden önemlidir?
- “Driven Design” kavramı ne ifade eder?
- DDD için “Domain Expert” neden gereklidir?
- “Bounded Context” nedir? Contextleri bulabilmek için hangi yöntemlerden yararlanılabilir?
- Domainler neden 3 ayrı başlık (Core, Generic, Supporting) altında değerlendirilir? Hangisine odaklanmalıyız?
Hazırsanız başlıyoruz.
Barış Velioğlu :
Öncelikle beni kırmayıp geldiğin için teşekkür ederim DDD. Seni tanımayan okuyucularımız için biraz kendinden bahseder misin?
DDD :
Davetin için çok teşekkür ederim Barış.
Çevremde beni genellikle işi yapan taraf olarak değil de işin nasıl yapılması gerektiğini söyleyen taraf olarak tanırlar. Bir anlamda yazılımların nasıl modellenmesi gerektiği konusunda danışmanlık yapıyorum diyebiliriz. Benim işim özetle gerçek dünyadaki iş modellerini herkesin anlayabileceği ortak bir dil ( Ubiquitous Language) oluşturarak dijital dünyaya uyarlamak. Elbette bunu yaparken birçok yöntemden yararlanıyorum.
Barış Velioğlu :
Kabul edelim ki bu fazlasıyla mütevazi bir giriş oldu. Neyse ki bugün senden çok bahsedeceğiz. Zira okuyucularımızın seni daha iyi tanımasını istiyorum. Müsadenle başka bir soruyla devam etmek isterim.
Senden danışmanlık alan bir firmada aldığın ilk aksiyon ne oluyor?
DDD :
Benimle çalışmayı göze alan firmalardan ilk istediğim şeylerden biri genellikle çözmek istenilen problemle daha önce yoğun bir şekilde çalışmış olan ve işin uzmanı olarak nitelendirilen en az bir kişi bulup özellikle problemin konuşulduğu ilk aşamada bizimle bolca mesai yapmasını sağlamak.
Ben bu arkadaşa “Domain Expert” diyorum ve öncelikle ondan dijital dünyaya uyarlanmak istenen sistemin gerçek dünyada nasıl çalıştığını tüm paydaşların — yani yazılımcıların, UI ve UX tasarımcılarının, proje yöneticilerinin, proje sahiplerinin ve ilgili diğer kişilerin — bir araya geldiği bir ortamda aktarmasını istiyorum.
Dikkat edersen burada biraz alışılagelmişin dışında bir şey istiyorum. Normalde yazılım projelerinin “çevirmeni” çok olur. Bir anlamda bilginin kulaktan kulağa aktarılması gibidir. Genelde projelerde paydaşların tümü bir araya gelmez. Özellikle yazılımcılar işin gerekliliklerini çıkartma sürecinin dışında tutulur.
Problemi analiz etme sürecinin içerisinde ise genellikle analistler başrol oynar. Şanslı olanları, işin uzmanı olarak nitelendirilen domain expertleri dinleme fırsatı bulur. Şanslı olmayanları ise sorunu yerinde kendileri analiz eder, zaman zaman da diğer paydaşlarla konuşarak problem domainini anlamaya çalışırlar.
Gereklilikler yazılımcılara geldiğinde onlardan problemin ne olduğuyla ilgilenmeleri beklenmez. Sadece çözüme odaklanmaları istenir.
Analistler problem domainini anlatırken özellikle sorunu çözecek olan mühendislerin anlayabileceği bir dil kullanmaya özen gösterirler. Aslında problemi çözecek insanlara yani yazılımcılara yardımcı olmak amacıyla yapılan bu eylem, nihayetinde sorunun başladığı yer ile çözümün başladığı yer arasındaki ilk ayrılık fitilini ateşler. Zira artık problemin dili ve çözümün dili değişmeye başlamıştır.
Kimi zaman analistlerin bu hazırlık aşaması sistem gereksinim dokümanı (System requirement document) olarak, kimi zaman ise iş analiz modeli (Business Analysis Model) şeklinde vuku bulur.
Bunun yanı sıra zaman zaman yazılımcıların inisiyatif alarak tamamen kendi jargonlarını kullanmaya karar vermesiyle durum daha da karmaşık bir hal almaya başlar.
Barış Velioğlu :
Ne demek istediğini çok iyi anlıyorum. Zira ne zaman bir proje yöneticisi ya da ürün sahibi mevcut projeyle uğraşan bir yazılımcıyla konuşacak olsa öncelikle kullandıkları terimlerin kendilerince ne anlama geldiğini anlamaya çalışırlar. Yani bir anlamda çevirmene ihtiyaç duyarlar. Yazılımcı “kullanıcı” derken, proje sahibinin aynı kavrama “müşteri” demeyi tercih ettiği birçok duruma bizzat şahit oldum.
EventStorming kavramının yaratıcısı Alberto Brandolini’nin ve Albert Einstein’ın bu konuyla da bağlantılı olabileceğini düşündüğüm şu anlamlı sözlerini paylaşmak istiyorum.
“Yazılım geliştirme bir öğrenme sürecidir; çalışan kod ise bu sürecin yan etkisidir.” — Alberto Brandolini
“Eğer bir problemi çözmek için yalnızca 1 saatim olsaydı, zamanımın 55 dakikasını problemi düşünerek, kalan 5 dakikasını ise çözümü düşünerek harcardım.” — Albert Einstein
Yani senin de söylediğin gibi, yazılım geliştirenlerin problemleri çözebilmeleri için öncelikle problem domainini çok iyi anlamaları gerekiyor. Bunu da en doğru şekilde yapabilmek için problemi ilk ağızdan yani mümkünse domain expertlerden bizzat dinlemeleri gerekiyor.
DDD :
Kesinlikle öyle Barış.
Araştırmalar bilgiyi paylaşmanın yeterli olmadığını gösteriyor. Bilgiyi paylaşmak kadar onu nasıl paylaştığımızın rolü de oldukça önemli. Yani bir yazılım projesinin başarılı olup olamayacağını proje içerisindeki iletişimle anlamak mümkün olabiliyor. Ne yazık ki yazılım projelerin çoğunda etkili bir iletişim dili kullanıldığını söylemek çok güç. Bu sebeptendir ki bu projelerin çoğu başarısızlıkla sonuçlanıyor.
Barış Velioğlu :
Uzun bir süredir konuşuyoruz ancak hala teknik bir şeyler konuşmadığımızı farkettim.
Buradan anladığım kadarıyla DDD olarak firmalar için herhangi bir teknolojik seçim yapmıyorsun. Problemin net bir şekilde tanımlanabilmesine yardımcı olup, uygulamayı geliştiren insanlar ile iş modelini bilen insanlar arasında bir anlamda iletişim köprüsü kurmayı öncelikli hedefin olarak belirlemiş gibisin. Bu iletişim köprüsüne de daha önce bahsetmesek de “ Ubiquitous Language” dediğini biliyorum.
Bunun yanısıra gerçek dünyada olduğu gibi dijital dünyadaki nesnelerin, rollerin ve onların sorumlulukların da net bir şekilde sınırlarını çizmeye çalışıyorsun ki buna da “Bounded Context” dediğini biliyorum. Özellikle bu kavramları okuyucularımızın çok iyi anlamasını istiyorum. Bu yüzden de bu konulara sohbetimizde bolca vakit ayırmak istiyorum.
Ancak bu kavramlara geçmeden önce piyasada sıklıkla karşıma çıkan Data Driven Design, Model Driven Design ve Event Driven Design isimli kavramlara dikkat çekmek istiyorum.
Mesela sen de Domain Driven Design olarak tanıtıyorsun kendini. Hepinizin adındaki bu “Driven Design” söz öbeğinin hikmeti nedir?
Mesela ben de eğer kendimi “Barış Driven Design” olarak adlandırmak istesem, nereden başlamam gerekiyor? Nedir bu Driven Design meselesi?
DDD :
“Driven Design” kavramı aslında “tasarım aklı kim” sorusunu sorar bize. Yani herhangi bir konu hakkında araştırma ve geliştirme yaparken ya da bir probleme çözüm ararken yaklaşımımızın ne olduğunu beyan etmek ister.
Kuzenim Data Driven Design’ı ele alalım. Ortada bir problem varsa öncelikle o problemle ilgili veri kaynaklarını belirler ve o kaynaklardan alabileceği tüm verileri almaya çalışır. Daha sonra o veriler üzerinden problemi analiz eder ve çözmeye çalışır. Yani yaklaşımının temelinde veri bulunur.
Bu örnekten yola çıkarsak eğer, birisine “Barış Driven Design” diyebilmemiz için o kişinin herhangi bir olaya ön yargısız bir şekilde en başından itibaren ilk önce barışı düşünerek yaklaşması gerekir. Yani ortada bir savaş var ise, bu savaştan nasıl en karlı çıkarız diye düşünülürse “Bencil Driven Design”, herkes için en barışçıl çözüm arayışı sergilenirse “Barış Driven Design” olur.
Ben ise Domain Driven Design olarak öncelikle domainin net bir şekilde anlaşılmasının gerekli olduğunu savunuyorum. Bunun da domain expertler ile yapılması gerektiğini düşünüyorum.
Barış Velioğlu :
Çok açıklayıcı oldu gerçekten. İsimlendirmelere çok takılan biriyimdir ve “Driven Design” kavramının çok başarılı bir soyad olduğunu düşünüyorum. Az kelimeyle çok şey anlatan, başarılı bulduğum nadir isimlendirmelerden diyebilirim.
İstersen biraz da “ Ubiquitous Language”in öneminden konuşalım. Sence yazılımcıların, domain expertlerin ve paydaşların aynı dili konuşması neden önemli?
DDD :
“Elinde çekiç olan her şeyi çivi zanneder” diye çok klişe bir söz vardır. Yazılımcılar da çözdükleri problemlerden bağımsız olarak nereye baksalar bir CRUD (Create, Read, Update, Delete) işlemi görmeye eğilimlidirler. Uygulamaların içinde Create, Update, Delete jargonunu bolca kullanırlar.
Gerçek dünyada bir firmanın müşterisine “silindiniz” CustomerDeleted dediğini hayal edin. Müşterilerin silinebildiği bir firmada, kimsenin müşteri olmak istemeyeceğine eminim. Gerçekte olan müşterilerin sizinle iş yapmayı bırakması ya da hizmet almayı durdurmasıdır CustomerLeft. Dijital dünyada bu olay bazı verilerin veritabanından silinmesiyle sonuçlansa bile, bu teknik detay gerçekleşen olaya adını vermemelidir.
DDD olarak yazılımların mümkün olduğunca gerçek dünyanın bir yansıması olmalarını istiyorum. Zira ihtiyaçlar ilk olarak gerçek dünyada ortaya çıkıyor. Bu durumda terminolojinin oluşmaya başladığı yer de aslında taleplerin oluştuğu sırada ortaya çıkıyor.
Peki o halde “ Ubiquitous Language” nedir? Neden önemlidir?
1- “ Ubiquitous” kelime anlamı olarak “her yerde bulunan/sık rastlanan” anlamına gelir. Yani bu ifade ile çözüm içerisinde kullanılan dilin(yazılı ve sözlü) kişiye özel olmaması gerektiği vurgulanmaya çalışılır.
2- Bir şeye anlamlı bir isim verebilmek dünyanın en zor şeylerinden biridir. Var olan ve alışılagelmiş isimleri kullanmak hem zaman kazandırır hem de çözümü konuşmayı kolaylaştırır.
3- Her ne kadar günümüz iş dünyasında, eskiye göre iş yapış şekilleri ve müşteri talepleri hızlı bir şekilde değişse de, yine de domainler yazılımcılara (sık sık iş değiştirme) göre daha statiktir.
Yazılımcılar isimlendirme standartlarıyla pek ilgilenmezler. Firmalar da ayrıca bu konuya gerektiğinden az önem verir. Yazılımcıların uygulama içerisinde kullandıkları isimler günlük ruh hallerine göre bile değişkenlik gösterebilir. Dolayısıyla ekip ya da firma içerisinde isimlendirme konusunda tutarlılık göstermek bir yana , yazılımcıların kendileriyle bile çeliştikleri durumlar olur. Bazen Delete sözcüğünü kullanırken, bazen Remove sözcüğünü kullanmaya karar verirler ve sorduğunuzda nedenini kendileri bile bilmez ya da hatırlamazlar.
Gerçek dünyada ise domain, nereye giderseniz gidin aynı terminolojiyi kullanır. Domain Expertler değişse de, terminoloji aynı kalır.
4- DDD yaklaşımında süreç domain ile başlar ve domain ile gelişmeye devam eder. Bu durumda terminolojinin yaratıcısı da domainin ta kendisi olmalıdır.
5- Problemler her ne kadar gerçek dünyaya ait olsa da, konuşulan çözüm içerisinde veritabanları, cachelemeler, servisler, güvenlik ve benzeri birçok konu daha bulunur ve bu sebeple de tek başına Domain Expert “ Ubiquitous Language” oluşturmak için yeterli değildir. Yine de teknik konuları “Ubiquitous Language” içerisinde minimum tutmaya özen gösterip detaya girmekten kaçınmak gerekir.
Ubiquitous Language’i genel olarak bu şekilde tanımlayabilirim. Umarım yeterince açıklayıcı olabilmişimdir.
Barış Velioğlu :
Bence harika bir cevap oldu. Geçtiğimiz aylarda “Konuşmanın İmkansızlığı Üzerine Bir Diyalog” isimli Osman Çakmakçı tarafından kaleme alınmış bir kitap okumuştum. O kitapta da insanların birbirleriyle konuşmalarının kelimelere yükledikleri farklı anlamlar neticisinde çok zorlaştığını, hatta birbirlerini tam olarak anlamalarının yaşam hikayelerinin farklılığı sebebiyle neredeyse imkansız olduğunu anlatıyordu.
Yine de imkansız diyerek konuşmanın, yani anlaşmanın mümkün olamayacağı anlamını çıkartmamalıyız. Ancak ortak bir dil oluşturmanın gerçekten de zor, zaman alan ve önemli bir iş olduğunu gözardı etmemeliyiz ki DDD olarak senin de bu konuya çok önem verdiğini söylediklerinden anlayabiliyorum.
Aynı netlikte senden Bounded Context kavramını anlatmanı istiyorum. Nedir bu Bounded Context, ondan bu kadar bahsedilmesinin nedeni ne sence?
DDD :
Ubiqutious Language hakkında bu kadar konuştuktan sonra Bounded Context’i konuşmak için sanırım bundan daha iyi bir fırsat olamazdı.
Bounded Context, bir domain içerisinde en az bir tane olup, sınırları belli olan ve bu sınırlar içerisinde kendisine ait bir dil bulunduran, farklı bounded contextler ile ilişkili olabilen ancak bağımsız hareket eden bileşenlere denir.
Böyle denir denilmesine de, bu tanım ile bu kavramı anlamanın pek de kolay olduğunu söyleyemem.
Barış Velioğlu :
İtiraf etmem gerekirse Bounded Context hakkında daha önce bir şey okumamış ya da duymamış biri için söylediğin tanım yeterince anlaşılır değil. Hadi gel biraz daha basitleştirmeye çalışalım.
Öncelikle “Bounded” ve “Context” kelimelerinin anlamlarına ayrı ayrı bir göz atalım istersen.
Kelimelerin Türkçe anlamlarından yola çıkarsak ve bunları birleştirirsek nihayetinde “Sınırlandırılmış İçerik/Durum” gibi bir anlam elde ediyoruz. Bounded kısmı nispeten çok daha net olmakla birlikte, özellikle Context için güzel de bir örnek verilmiş.
Eğer bir şeyi anlamıyorsanız, onun içeriğinin/bağlamının farkında olmamanızdandır.
Bağlam ifadesinin TDK’daki karşılığına da bir bakalım.
Bir dil birimini çevreleyen, ondan önce veya sonra gelen, birçok durumda söz konusu birimi etkileyen, onun anlamını, değerini belirleyen birim veya birimler bütünü, kontekst.
Bağlam ifadesinin Türkçe anlamının bile oldukça karmaşık olduğunu itiraf etmeliyim.
Ben “Bounded Context” kavramının “Bounded Perspective” olarak da ifade edilebileceğini düşünüyorum. Baktığımız şey aynı olsa da, gördüğümüz şey farklı olabilir. Duyduğumuz kelime aynı olsa da, farklı bağlam içerisinde ifade edilmek istenen şey farklı olabilir.
Anlamın değişime uğradığı noktada da “Boundary” dediğimiz sınırlar belirginleşmeye başlar ve “Bounded Context” oluşur.
DDD :
“Bounded Perspective” ifadesini sevdim ama izninle ben “Bounded Context” demeye devam edeceğim.
Sonuç olarak problemin herkes tarafından anlaşılabilmesi ve kolayca konuşulabilmesi için ortak bir dil belirlemek şart. Bu nedenle problemin ve çözümün muhattapları bir araya gelerek bu ortak dili yaratmalı ve bu dilin sınırlarını net bir şekilde belirleyerek Domain içerisindeki Bounded Contextleri oluşturmalıdır.
Bounded Contextleri, yani bağlamların sınırlarını belirlemek oldukça karmaşık bir iştir. Zira bu sınırlar gerçek dünyada da fazlasıyla birbirinin içerisine geçmiş olup, bağlamlar arasında bulanık kesişim noktaları bulunabilir. Kimin sorumluluğu nerde başlıyor nerde bitiyor gibi bulanıklıkları tespit etmek ilk bakışta pek kolay olmayabilir. Bu durumda projenin ilerleyen aşamalarında bağlamsal sınırların değişebileceği varsayılarak ilerlenmelidir.
Barış Velioğlu :
Yavaş yavaş sormak istediğim o önemli soruya gelmiş olduk. Peki Bounded Contextler nasıl bulunur?
DDD :
Uzunca bir cevaba hazır ol. Zira bu sorunun çok net bir cevabı olmamakla birlikte contextleri bulma konusunda elbette bazı kavramlardan yararlanıyorum.
Kullandığım yöntemlerden biri, daha önce de konuştuğumuz gibi domain hakkında konuşurken, konuşulan dile pürdikkat kesilmek. Zaman zaman benzer, hatta aynı kelimeler farklı anlamlar ifade etmeye başlayabilir. Dilin tam bu farklılaşmaya başladığı noktalar, bize farklı sınırlar içerisinde bulunduğumuzu işaret eder.
Kullandığım diğer yöntem ise kendime “hangi seviyede transactional tutarlılığa ihtiyacım olup olmadığını” sormak. Örneğin; bir satış domaini üzerinde çalıştığımızı varsayalım. Sistemde de binlerce ürünümüz olsun.
Soru şu. Biz bu ürünlerin açıklamalarını ve stok miktarını aynı anda güncellemek ister miyiz?
Barış Velioğlu :
Düşünüyorum… Muhtemelen asla böyle bir şey yapmak istemeyiz.
DDD :
Kesinlikle öyle. Bu örnekte bu sınırları çizmek biraz daha kolay görünse de bazen bu kadar kolay olmayabiliyor. Bu gibi durumlarda da sınırlar bulanıklaşmaya başlıyor.
Buradaki örnekte ürünün açıklaması ile ürünün stok miktarı ürüne ait özellikler gibi görünse de, bunlar genellikle ayrı ayrı zamanlarda güncellenen alanlardır. Bu da bize ürünün birden fazla contextde bulunabileceğine işaret eder.
Burada biraz sezgisel davrandık ancak benimle çalışmanın olmazsa olmazlarından biri de şüphesiz heuristic yani sezgisel olabilmekten geçiyor.
Barış Velioğlu :
Özellikle bazı durumlarda tam olarak o rasyonel cevabı bulamadığımda sezgisel hareket etmenin gerçekten faydasını görüyorum.
Peki başka ne gibi yöntemler söyleyebilirsin bize?
DDD :
Demek hala sıkılmadın ve dinlemek istiyorsun.
Barış Velioğlu :
Lütfen devam et.
DDD :
Son yıllarda digitize (sayısallaştırmak), digital transformation (dijital dönüşüm) gibi kavramlarını sıkça duyar olduk. Bu kavramlar çoğunlukla mevcut düzende yarattığımız fiziksel dünyayı, dijital dünyaya aktarmanın yollarını arıyor.
Her ne kadar insanların aklına çoğu zaman dijital dönüşüm ile Paperless (kağıtsız), E-Devlet, E-Nabız, Endüstri 4.0 geliyor olsa da dijital dönüşümün asıl değer yarattığı nokta, bu sistemlere aktarılan verilerin kullanılarak yeni iş modelleri oluşturmak olduğunu söyleyebilirim.
Konumuz bu değil biliyorum ancak bundan bahsetmemin sebebi şu; günümüzde dijitalleşen ya da dijitalleştirilen iş modellerinin çoğunun zaten fiziksel dünyada bir karşılığı bulunuyor. Bu yaklaşıma “Pyhsical-World-First” yani “İlk-Önce-Fiziksel-Dünya” yaklaşımı diyebiliriz.
Bunun yazılımcılar için oldukça tanıdık bir tabir olduğunu da söyleyebilirim. Örneğin; bir projeye başlarken veri modelinizi ilk önce veritabanından başlayarak oluşturuyorsanız “Database-First”, veriyi kod yazarak modelliyorsanız “Code-First” deniliyor. Projenizi ilk başta mobil cihazlara uyumlu olarak geliştiriyorsanız “Mobile-First”, ilk başta masaüstü cihazlara uyumlu olarak geliştiriyorsanız “Desktop-First” deniliyor.
Ancak günümüzde “İlk-Önce-Fiziksel-Dünya” yaklaşımı genellikle bir seçim değil, çoğu zaman kaçınılmaz bir gerçek olarak ortaya çıkıyor. Zira uğraştığımız domainlerin bir çoğunun fiziksel dünyada bir karşılığı bulunuyor. İş senaryolarının hemen hemen hepsi yıllardır fiziksel dünyamızda denenmeye ve kullanılmaya devam ediyor. Bu da bir anlamda işimizi kolaylaştıran faktörlerin başında geliyor.
Özetlemek gerekirse fiziksel dünyada sınırları belirlenmiş, yıllarca denenmiş ve bir şekilde verimliliği ispatlanmış modelleri genellikle dijital dünyaya modellemeye çalışıyoruz. Şüphesiz fiziksel dünyadaki tecrübelerimizden yararlanmamız gerekiyor.
Örneğin; iş yerlerindeki departmanları ya da takımları düşünelim. Bu oluşumların kendi içlerinde belli kuralları, sorumlulukları yani doğal sınırları bulunur. Nihayetinde ilgili işin amacı “otomobil üretmek” olabilir. Ancak bu amacı gerçekleştirebilmek için birçok departman ya da takım birlikte çalışmak zorundadır. Bu departmanların ya da takımların birbirleri ile olan ilişkileri, iş yapma şekilleri ve sorumlulukları da bize contextleri ve bu contextlerin sınırlarını oluşturmamızda yardımcı olur. Ancak unutmamak gerekir ki, bu sınırları çizmek her zaman çok kolay değildir ve bazen sezgisel belirlenmeleri gerekebilir. İş modelleri ve dolayısıyla iş yapış şekilleri değişime uğradıkça da sınırlar ve sorumlulukların değişebileceği de unutulmamalıdır.
Örneğin geçtiğimiz aylarda Amazon Türkiye, Prime özelliğini duyurdu. Prime üyelik sayesinde ücretsiz kargo, ertesi gün teslimat ve özel indirimler gibi birçok yeni özellik Amazon platformuna eklenmiş oldu.
Bu özellik ile birlikte kullanıcı nesnesine yeni bir üyelik tipi mi eklendi yoksa IsPrime diye ayrı bir alan mı açıldı, bunun bir önemi yok. Böylesi bir iş kuralının domain üzerindeki etkisine bakmamız gerekiyor. En basit haliyle bile bu özellik aşağıdaki contextlerin tümünde bir değişimi tetikliyor.
- Shipping Context (Nakliye Bağlamı)
- Discount Context (İndirim/Kampanya Bağlamı)
- Membership Context (Üyelik Bağlamı)
Yani eklenmesi planlanan özelliklerin sistemin davranışını nasıl değiştirdiğine bakmamız gerekiyor. Bunu bir anlamda etki analizi yapmak gibi düşünebilirsiniz. Ancak buradaki en büyük fark her context kendi içerisindeki etkiyi analiz etmelidir.
İndirimler ve kampanyalardan sorumlu departman, Prime özelliğinin kendisini nasıl etkileyeceğini düşünmelidir. Yine aynı şekilde nakliye departmanı da Prime ile gelen ücretsiz kargo ve ertesi gün teslimat özelliğinin onlara olan etkisini incelemeli ve contexti yeni kurallara uyacak şekilde değiştirmelidir.
Barış Velioğlu :
Boundary Contextleri bulma yöntemlerini saatlerce konuşmaya devam edebileceğini biliyorum. Bence bu konuya söyleşimizin sonunda okuyucularımızdan soru gelirse tekrar değinebiliriz.
Seninle konuşmak istediğim başka bir önemli konu daha var. Domainleri tek kategoride değerlendirmediğini ve onları da kendi içinde alt kategorilere ayırdığını biliyorum.
- Core Domain
- Supporting Domain
- Generic Domain
Bu kategorilendirmenin amacından biraz bahseder misin?
DDD :
Domain kavramının çok geniş ve soyut bir kavram olduğunu itiraf etmeliyim. Bu sebeple de onu söylediğin gibi üç farklı kategoride değerlendirmenin faydalı olabileceğini düşündüm. Bu sayede projenin özellikle hangi kısmına odaklanılması gerektiğinin anlaşılmasını sağlamaya çalıştım.
Core Domain; bir organizasyonu diğerlerinden ayıran ve özel kılan en önemli domain parçasını temsil eder. İlgili organizasyonun başarılı olmasının anahtarı bu core domaini sorunsuz bir şekilde uygulayabilmesinden geçer. Bu sebeple de core domain, organizasyonlar için en öncelikli olması gerekendir. Ayrıca organizasyonun en iyi yazılımcıları da genellikle bu domain üzerinde çalışmalı ve gereken efor da diğer alt domainlere nazaran daha fazla olacak şekilde planlanmalıdır.
Büyük domainlerde birden fazla, küçük domainlerde ise tek bir core domain bulunabilir. Özellikle core domainleri organizasyon içerisinde sıfırdan geliştirmeye ve bu bilginin (know-how) de organizasyon içerisinde kalmasına özen gösterilmelidir.
Supporting Domain; diğer domain türleri gibi organizasyon için olmazsa olmaz olsa da, geliştirilmesi core domaine göre çok daha kolaydır. Genellikle dışardan satın alınabilecek kadar generic değildirler ancak bu domainler için en iyi yazılımcılarınızı görevlendirmeniz de gerekmez. Bu tip domainler adından da anlaşılacağı gibi genellikle core domaini destekleyici bir rol oynarlar.
Generic Domain; organizasyona özel bir durum içermeseler de yine de uygulamanın bütünü için gereklidirler. Bu tip domainler genellikle üçüncü parti yazılımlar veya servisler olarak direkt satın alınabilirler. Bu sayede özellikle zamandan tasarruf edilir. SMS sistemi ya da ödeme sistemleri genellikle generic domaine verebilecek en güzel örneklerdendir.
Yine de unutulmamalıdır ki bir organizasyon için generic olan bir domain, başka bir organizasyon için core olarak değerlendirebilir. Örneğin, devletlerin e-nüfus sistemi için kimlik yönetimi core bir domaindir. Ancak müşteri ilişkilerini yöneten bir firma için müşteri kimliği generic bir domain olarak nitelendirilebilir. PayPal için ödeme sistemi core domaindir, ancak Spotify için ödeme sistemi generic bir domain olabilir.
Özetle bu domainlerin tümü nihai çözüme ulaşmak için gereklidir. Herhangi birinin olmaması durumunda çözüm tamamlanamaz. Ancak aralarında en çok özen gösterilmesi ve zaman harcanması gereken core domaindir. Zira rakiplerinize core domaininiz ile gözdağı verirsiniz.
Barış Velioğlu :
Düşündüğümden de iyi özetledin DDD. Böylece sormak istediğim son sorunun da cevabını vermiş oldun.
“Teknolojiyle Diyalog” konseptinin ilk konuğu olmayı kabul ettiğin için tekrar çok teşekkür ederim.
Bugünkü sohbetimizde daha çok aldığın stratejik kararlardan ve bu kararlarını temsil eden kavramlardan bahsettik.
Bu konuştuğumuz stratejik kararlarının yanısıra, biraz da uygulamaya yönelik taktiksel çözüm kalıplarının olduğunu da biliyorum. Sohbetimizin ikinci bölümünde de bu kalıplardan bazılarını konuşmayı çok isterim.
DDD :
İtiraf etmeliyim ki zor olandan başladık Barış. Taktiksel kalıplarımı konuşurken işimizin biraz daha kolay olacağını düşünüyorum.
Bu arada davetin için tekrar teşekkür ederim. Benim için de çok keyifli bir sohbet oldu. Diğer söyleşimizi şimdiden iple çekiyorum.
Barış Velioğlu :
Son olarak seninle iletişime geçmek isteyen okurlarımız olursa, sana nasıl ulaşabilirler?
DDD :
Her ne kadar fazlasıyla teknolojinin içinde olsam da, günümüz iletişim araçlarından izole bir hayat sürüyorum. Eğer bana gerçekten ihtiyacınız olduğunu düşünüyorsanız okuyucularına şu iki kitaptan başlamasını tavsiye ederim. Mavi kitabı işin teorisini merak edenler, kırmızı kitabı ise işi uygulayarak öğrenmeyi sevenlere tavsiye ederim.
- Implementing Domain-Driven Design — Vaughn Vernon
- Domain-Driven Design : Tackling Complexity in the Heart of Software — Eric Evans
Barış Velioğlu :
“Teknolojiyle Diyalog” konseptinin ilk konuğu DDD oldu. Kendisine tekrar teşekkür ediyorum. Bir sonraki konuğumu belirlemek isterseniz, yorum bölümünü kullanabilirsiniz.
Hoşçakalın. Takipte kalın (:
Kaynaklar
- https://martinfowler.com/bliki/BoundedContext.html
- https://www.microsoftpressstore.com/articles/article.aspx?p=2248811
- https://docs.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
- https://www.infoq.com/presentations/microservices-ddd-bounded-contexts/
- https://www.atlascode.com/blog/why-software-projects-fail/#:~:text=timescales%20or%20budgets-,Percentage%20of%20Projects%20That%20Fail,in%20partial%20or%20total%20failure.
- https://vaadin.com/learn/tutorials/ddd/strategic_domain_driven_design
