İş Değeri ve Domain-Driven Design
Parlak şeyler biz yazılımcıları büyüler. Bu öyle bir büyüdür ki, geliştireceğimiz projelerdeki modelleme ve geliştirme süreçlerinde körleşmemize, tercihlerimizi bir an önce kullanmak istediğimiz bu parlak nesneler etrafında şekillendirmemize neden olabilir. Adeta bir Gollum edasıyla Kıymetlimiss diye tıslayarak sahiplendiğimiz bu parlak şeyler yaydıkları göz kamaştıran ışıklarıyla, aslında yazılımı geliştirmemizin tek nedeni olan iş değerini gözden kaçırmamıza sebebiyet verebilirler.
Makale ya da online seminerlerden oluşan Türkçe kaynaklara baktığımda, domain-driven design (DDD) konusunda da az çok yukarıda sözünü ettiğim büyülenme durumunun hakim olduğunu görüyorum. Genelde DDD’nin koda daha yakın olan, yazılımcılar tarafından heyecanla uygulanabilecek taktik desenlerine odaklanılıp, iş için asıl değeri keşfetmemize imkan kılan stratejik desenler arka plana itiliyor gibi görünüyor. Oysa ki DDD’nin stratejik desenleri kullanılarak tasarım gerçekleştirilmeden, taktik desenlerin (aggregate, entity, domain services vb.) uygulanması mümkün değil. Gerçek ihtiyacı görmeden, kod geliştirme aşamasında uygulanan tasarım desenleri, ürünün asıl hedefini ıskalamaya ve gereksiz bir şekilde karmaşık, sonradan anlaşılması zor ve en önemlisi iş süreçlerinden kopuk mimarilerin ortaya çıkmasına neden oluyor. İş değeri üretmeyecek alanlarda mükemmel tasarım peşinde koşma tutkusu nedeniyle, bir dünya efor boşa gidiyor. Nick Tune bu konuda şöyle diyor:
It is far better to have small balls of mud, isolated from other contexts that can easily be replaced, rather than trying to strive for beautiful code everywhere.
Bu yazıda taktik desenlerden uzaklaşıp, DDD’nin asıl iş değeri üreten desenlerine odaklanmak istiyorum.
DDD’nin organizasyona kattığı değer nedir?
Bundan onlarca yıl önce, yazılım kalitesinin babası olarak görülen Watt S. Humprey şöyle demiş:
“Every business is a software business.”
Bu sözün bir benzerini Satya Nadella’nın “Every company is now a software company” şeklinde tekrar ettiğini görmüş olabilirsiniz. Sektörden ve faaliyet alanından bağımsız olarak, yazılımlar artık organizasyonların kalbinde, asıl değeri üretmeyi mümkün kılan kaynaklar olarak yerlerini aldılar. Yazılımlar, organizasyonların operasyonel süreçlerini hızlı bir şekilde dönüştürüyor. Teknolojiye yaptıkları yatırımlarla orantılı olarak, organizasyonların değer teklifleri artıyor ve rekabet avantajı elde ediyorlar.
Dışarıdan temin edilecek hazır yazılım çözümleri ile organizasyonların ihtiyaçlarının bir kısmı karşılanabilir olsa da, gerçek değeri üretmek ve rekabet edebilmek için hazır çözümlerin yetersiz kalacağı aşikar. Dolayısıyla dijital dünyada serpilebilmek için, bir organizasyonun sahip olması gereken en önemli yetkinliklerden biri yazılım geliştirebilme kabiliyetidir. Peki bu yetkinlik ile DDD arasındaki bağlantı nedir?
DDD, karmaşık iş ihtiyaçlarını karşılayabilmek için uygulanabilecek, iş için en yüksek değeri üretmeye odaklı bir yazılım geliştirme metodolojisidir.
Bu tanımdan yola çıkarak, DDD’nin değer üretme yolunda hangi engellere çözüm sunduğunu inceleyelim.
Ortak bir dil geliştirilmesi
En sık görülen ve acısı en şiddetli olan sorunlardan biri iş uzmanları ve geliştiricilerin ortak bir dilde buluşamıyor olmalarıdır. İş uzmanlarının kullandığı dili tam olarak anlamayan geliştiricilerin, kendilerine göre bir dil oluşturmaları ve bu dilin iş ihtiyaçları ile örtüşmemesi şeklinde tanımlayabiliriz bu durumu. İş süreçleriyle örtüşmeyen bu dilin üzerine “mükemmel” mimari inşa edildiği durumda gereksiz sarf edilen bir eforla karşılaşmak ise kaçınılmazdır.
Yazılımın başarılı olabilmesi için iş uzmanlarının ve geliştiricilerin aynı dili konuşmaları gerekir. DDD’nin babası Eric Evans’ın ubiquitous langugage olarak isimlendirdiği bu dil, iş uzmanları ve geliştiricilerin birlikte çalışarak ortaya çıkardığı ve düzenli olarak geliştirdiği bir terimler sözlüğü gibidir. Bu tanıma, sadece aynı kelimeleri kullanmak, aynı terminolojiye sahip olmak şeklinde bakmamak gerek. Bu dilin ortaya çıkartılması, iş uzmanlarındaki değerli bilginin geliştiricilere akmasını ve aynı zamanda iş uzmanlarının da tasarım sürecine dahil olmalarını ve en önemlisi, genelde birbirinden kopuk olan bu iki profilin çözüm yolunda ortak bir anlayış geliştirmesini sağlar.
Bu ortak dilin oluşturulması sürecinde, anlaşılmaz dokümanlardan, ardı arkası gelmeyen tartışmalardan uzak durup, yapıcı iletişimi destekleyecek şekilde görsel araçlar kullanmak çok faydalı olacaktır. Son zamanlarda gittikçe artan bir yoğunlukta uygulanmaya başlanan ve bizim de artık her projenin başında olmazsa olmaz gözüyle baktığımız Event Storming yöntemi ile bu ortak dilin oluşturulmasını çok hızlı ve etkin bir şekilde gerçekleştirebilirsiniz.
Problemin özünün keşfedilmesi
Karmaşık bir probleme getirilen çözüm elbette bir çok bileşenden oluşacaktır. Ancak tüm bu bileşenler iş değeri açısından aynı derecede önem taşımayabilir. Dolayısıyla tüm eforu tüm alanlar için sarf etmek yerine, önem taşıyan alanlara odaklanmak gerekiyor. DDD’nin bu noktada önerisi, problemi alt alanlara ayırmak ve bazı sorularla bu alanlardan hangilerinin asıl değeri üreten alan olduğunu keşfetmek şeklinde.
Mobil oyun geliştiren bir firma olduğumuzu düşünelim. Bu durumda problem alanını oluşturan domain şu şekilde gösterilebilir:
Bu sistemi oluşturan bir çok farklı bileşen olması gerektiği aşikar. Bu domain’i aşağıdaki şekilde alt domain’lere bölümlendirebildiğimizi düşünelim:
Yukarıda sözünü ettiğim event storming oturumları ile bu alt domain’lerden hangilerinin asıl odak gerektiren (core) domain, hangilerinin genel ve destekleyici domain oldukları ortaya çıkacaktır. Domain uzmanları ile yapılan oturumlardan sonra domain’lerin şu şekilde belirlendiğini varsayalım:
Oyunların tasarlanması (burada kast edilen görsel tasarım değil, game design) ve oyunun kodlanması ile ilgili tüm faaliyetlerin oyun geliştirme işinde birer Core Domain olduğu sonucu çıkıyor. Bu oyun firmasının en büyük efor yatırımı yapması ve elindeki en iyi kaynakları kullanması gereken alanlar bu iki alandır diyebiliriz. Bu firmanın başarılı olabilmesi için iyi bir oyun tasarımı ve kaliteli bir kodlama gücüne sahip olması şart.
Core haricindeki domain’ler ise bir şekilde dışarıdan satın alınabilecek, ya da yine firmanın kendisinin geliştirebileceği ancak bunu yaparken en yetkin kaynaklarını kullanması gerekmeyen, Nick Tune’un dediği gibi small balls of mud şeklinde bile üretilebilecek çözümler olabilir.
Core domain’in keşfedilmesi, yatırımın, daha genel çözümlerle ya da dışarıdan alınabilecek yazılımlarla halledilebilecek sorunların çözümüne yapılmasının önüne geçmesi açısından son derece önemli.
Sınırların belirlenmesi
Yukarıdaki domain şemasında görebileceğiniz gibi, her işletmede birden çok alt domain olabilir. Yukarıdaki şemada göstermedim ancak bir çok işletmede bir muhasebe departmanı vardır. Muhasebeyi de genelde dışarıdan satın alınan yazılımlarla çalıştıklarından ötürü generic bir alt domain olarak göstermekte sakınca yok. Doğal olarak bu alt domain’in de kendi içinde kullandığı farklı bir dil olması kaçınılmaz. Pazarlama departmanı içinde Oyuncu olarak isimlendirilen bir varlık, muhasebe departmanında Hesap olarak isimlendirilebilir.
Tüm modelde aynı dili kullanmanın mümkün olmadığı buradan görülebilir. Üstelik işletmenin her alanında aynı dili kullanarak bir çözüm geliştirmeye çalışmak felakete davetiye çıkarmaktan başka bir işe de yaramaz. Öyleyse çözüm geliştirilirken, problemin parçası olan yukarıdaki alt domain’lerin birbirlerinden farklı bir terminoloji ile, daha doğru bir ifadeyle ubiquitous language ile ayrılması gerektiğini söyleyebiliriz.
Sınırları farklı bir dil ve dolayısıyla farklı modellerle ayrılmış olan alt domain’lere bounded context ismini veriyoruz. Her bounded context içinde sadece ve sadece tek bir takımın çalışmasına izin vererek, izlenmesi gereken yöne dair net bir algı oluşturmak, birbirlerinden bağımsız çözüm gerektiren alanların net çizgilerle ayrışmasını sağlamak ve bu sayede ortaya bir big ball of mud çıkmasını engellemek organizasyonun kendi yapısını da daha iyi anlamasını ve ortaya faydalı bir model çıkmasını sağlayacaktır.
Özetle, bir çözüm geliştirme yolunda, yazılımcılar olarak hemen kodlamaya dalma hevesimizi bir kenara bırakıp DDD’nin bize sunduğu stratejik yöntemleri iyi bir şekilde uygulayarak, iş uzmanları ve geliştiriciler arasında ortak bir algı oluşturabilir, çözüm yolunda gerçek odak gerektiren alanları net olarak tespit edebilir ve organizasyonun kendisini daha iyi anlamasını sağlayarak gerçek bir iş değeri oluşturabiliriz.
Faydalı bulduysanız bol bol alkışlamayı ve beni takip etmeyi unutmayın :-)
