Domain Storytelling — Domain Story’lerden Domain Modele

“A good domain model prevents programmers (and users) from breaking the rules of the domain.” — Domain Storytelling (Hofer, Schwentner)

Selamlar,

Serinin devam eden bölümlerinde, Domain Storytelling kitap bölümlerinin özetlerini yapmamızın yanı sıra Lodera ismini verdiğimiz işletmenin kurgusunu oluşturarak bu işletmenin domainini keşfetmek üzere farklı detay seviyelerinde domain story’ler kaydettik. Amacımız business’ı anlamak, subdomain’leri — problem alanını — keşfetmek ve bu keşiflerle elde ettiğimiz bilgilerle bir yazılım sisteminde ifade edilebilecek şekilde bounded context — çözüm alanı — tasarımı yapabilmekti.

“New Project” ya da “Refactor” butonuna basmadan önce katlanmamız gereken bazı bedeller vardır. Serinin on dördüncü bölümüne kadar, Domain Storytelling, User Stories ve User Story Mapping tekniklerinin bir kombinasyonuyla ortaya çıkardığımız çalışmalar sayesinde bu bedelleri ödedik. Lodera vaka çalışmaları örneğinde müşteriye işi nasıl yaptığını sorduk, anlatılanları domain story olarak kaydettik, kayıt üzerinde müşteriyle tartıştık, business içerisindeki bir adımın gerçekten yazılım sistemi tarafından desteklenip desteklenmeyeceğini anlamak için gereksinimlerin belirlenmesine dair kritik sorular sorduk ve böylece işin her adımını yazılım sistemine taşımadık. Sürecin en değerli çıktısı olarak herkesin üzerinde tartışabileceği yaşayan bir organizma — domain story — oluşturduk. Bu organizma, iş süreçlerindeki yasal ya da operasyonel ihtiyaçlardan etkilenerek evrilecek; doğruluğu ve sınırları sürekli sınanabilir ve ölçülebilir olacaktır.

Bu bedel, yazılım sistemindeki tek problemimizin teknik konular olması için ödendi. Bu sürece hak ettiği zamanı ayırmamanın — bu bedeli ödemekten kaçmanın — güçlü teknik altyapılara sahip yazılım sistemlerine bir fayda sağlamadığını günümüz projelerinden anlayabiliriz. Nitekim seri boyunca herhangi bir bölümde kullanılacak veritabanına, programlama diline ya da herhangi bir framework’e dair bir cümle bile paylaşmadık. Mimari herhangi bir karar vermedik; heyecanımıza yenik düşüp bir karar verecek olsaydık da bu karar süreci, mimarinin popülaritesinden bağımsız şekilde iş ihtiyacı odaklı olurdu.

Nihai amacımız, serinin bütün bu bölümlerinde bahsettiğimiz gibi, yalnızca diyagramlar çizmek ya da bir iş akışını formal olarak göstermek değildir. Hedefimiz, diyagramlarla yaptığımız modellemeden programlama dilleriyle yaptığımız modellemelere geçmektir. Kaydedilen domain story’ler ile keşfedilen domain bilgisi üzerine konuşurken kullanılan terimler, programlama dilleriyle yaptığımız modellemede de kendini göstermeli ve örtüşmelidir. Beyaz tahtadaki model, programlama dili modeline aktarılırken terimlerin ve bunlar arasındaki bağın korunması gerekir.

Domain’i yeterince iyi anlamadan kod yazmak, kaçınılmaz olarak verinin merkezde olduğu ve istenilen her yerden bu verinin manipüle edilebildiği anemic bir domain model ortaya çıkaracaktır. Vaka çalışmamızdaki kurgu işletmemiz Lodera’dan Contract için Şekil 3.26’da örneğini paylaştığımız model, anemic de olsa bir modeldir; ancak OOP’nin “nesne” tanımından oldukça uzaktır. Nitekim modelin anemic olmasının daha faydalı olduğu ya da olabileceği veri yoğun projeler de gerçek hayat örnekleri arasında yer almaktadır.

Figure 3.26: Anemic Domain Model

Şekil 3.26’da sözleşme fiyatının set edilmesi için, vaka çalışması bölümümüzden Şekil 3.21’in ikinci cümlesinde görüleceği üzere rota, tarih aralığı ve yük bilgilerinin sözleşmeye dahil edilmiş olması gerekmektedir ve bu, Contract için bir iş kuralıdır (policy). Ancak Şekil 3.26’da örneği verilen modele göre sözleşmenin fiyatı, Contract’ı tüketebilen her yerden ayarlanabilir durumdadır. Bu durum ise sözleşme fiyatının belirlenmesi ya da hesaplanması sürecine ait davranışların Contract’ı kullanan yere (client’a) sızması anlamına gelir. Contract gibi nesne olarak algıladığımız ya da öğrendiğimiz sınıflar, price ve benzeri özellikleri yalnızca barındırıyor ancak bunların hesaplanması ya da değerlendirilmesi davranışlarını içermiyorsa nesneye yönelimden bahsetmek mümkün değildir. Gerçek bir “nesne”, veri (price vb.) ve davranışı (calculatePrice, fillOut) birlikte kapsüllemeli ve barındırmalıdır. Dolayısıyla Şekil 3.26, bahsettiğimiz şekilde güncellendiğinde Rich Domain Model olarak Şekil 3.27 ortaya çıkar.

Figure 3.27: Rich Domain Model

Buraya kadar paylaşılanlardan, domain story’lerin ifade gücü yüksek ve domaini gerçekten yansıtan bir domain model tasarlamak için güçlü bir araç olduğu görülebilir. Domain story’ler, bir domainin yapısal (price, route, date range) ve davranışsal (calculatePrice, fillOut) yönlerini içermesi açısından oldukça önemlidir. Böylece domain story’lerden hareketle yapılan programatik modellemeler, OOP’nin ifade ettiği şekliyle doğru bir “nesne” algısının oluşmasına da katkı sağlar.

Üzerinde taşıdığı verinin ne zaman, nerede ve nasıl değişeceğini bilmediğiniz ya da takip edemediğiniz bir “nesne”den ziyade, veri ve davranışı kendi içinde tutarlı ve bir bütün halinde barındıran nesneler inşa etmelisiniz. Şekil 3.27’de sözleşme fiyatını değiştirebilen ve bu bilgiyi bilmesi gereken tek yer, onu hesaplayan metottur. Bu ya da buna benzer bir bilgiyi başka bir yerde aramak, yanlış nesne algısının ve domain sızıntısının bir sonucudur. Bütüncül ve tutarlı nesneler inşa etmek için domainde ne olduğunu anlamanız ve eylemlere bakmanız gerekir. Bunun için şu soruları sormalısınız:

Kullanıcılar hedeflerine ulaşmak için ne yapıyor?

Kullanıcılar hedeflerine ne üzerinden ve onu nasıl manipüle ederek ulaşıyorlar?

Kullanıcılar bilgiyi nasıl paylaşıyor ve birlikte nasıl çalışıyorlar?

Bu sorular aynı zamanda bir Domain Storytelling oturumunda sorulan sorulardır ve verilen cevaplar, hikaye formatında görseller ortaya çıkarır. Bu görsellerden domain model için girdiler oluşturabilirsiniz; nitekim Şekil 3.26 ve 3.27 bunun basit bir UML ara formatındaki örneğidir. Domain modelini doğrudan kodda ifade etmeden önce BDD, UML veya EventStorming gibi ara formatlarda ifade etmek, ortak bir anlayış oluşturmak ve kavramları netleştirmek açısından önemlidir. Bu çabalarla ve yukarıda bahsettiğimiz şekilde ödenen bedelle amaçlanan şey, domaini yansıtan bir domain model tasarlayabilmektir.

Bazen bizi en iyi tasarıma daha da yaklaştıran şey kodlamaya devam etmektir. Bazen de domain uzmanlarıyla birlikte Domain Storytelling gibi tekniklerle zenginleştirilmiş bir workshop düzenleyerek modellemeye dönmektir. Eric Evans bu süreci model exploration whirlpool olarak tanımlar. Evans’ın girdap (whirlpool) metaforuyla anlatmak istediği şey, modellemenin Domain Storytelling gibi tekniklerle yapılan beyaz tahta çalışmalarıyla başlayıp, ardından ara format modellemelere ve en sonunda programatik modellemeye doğrusal ve zorunlu bir sırayla ilerleyen katı bir süreç olmadığıdır. Bundan ziyade her modelleme formatında ya da kodlama sırasında domain kavramlarına dair yeni bir anlam keşfetmenizle başlayan döngüsel bir girdaptır.

Sonuç olarak domain story’ler, domainin yapısını, davranışını ve kurallarını içermesi bakımından domain modele geçmek için sağlam bir zemin hazırlar. İfade gücü yüksek bir domain model tasarımı sonrasında business’ı implemente etmeye başlayabilirsiniz. Yol boyunca aslında “ne” olduğunu anladığınız ya da netleştirdiğiniz kavramlarla karşılaştığınızda başlangıç noktasına dönerek domain story’yi güncelleyin ve herkesin bu “yeni” kavram üzerine konuşmalar yapmasını sağlayın. Çünkü bu kavram, bir başka “yeni” kavramın keşfine, bir başka sınırın daha belirginleşmesine ya da bu sınırın tamamen değişmesine sebep olabilir. Uzun süre değişim geçirmeyen bir domain model, muhtemelen yeterince derine inilmemiş bir modeldir ya da hiç yaşamıyordur; bu da modellerin yaşayan bir organizma olduğu düşüncesinden hareketle yanlış tasarlanmış bir modelin göstergesi olabilir. Bu noktada Domain Storytelling gibi konuşma/modelleme teknikleriyle domain modellerin, domain story’ler gibi kaynaklar üzerinden sınanmasını sağlayabilirsiniz.

Keyifli okumalar…