Domain Book

Domain book, hem ekip içerisindeki domain bazlı bilgi aktarım ve bilgiye ulaşma süreçlerinin, hem de ekibe yeni katılan üyelerin oryantasyon süreçlerinin daha verimli hale gelmesini sağlayabilecek, domain driven design felsefesine göz kırpan bir yöntem.

Bir yıl kadar önce Hepsiburada’nın recommendation ekibinde çalıştığım dönemde, ekibe katıldıktan sonra kendi oryantasyon sürecimde sorduğum soruların aynılarını, ekibe benden sonra katılan arkadaşlarımın da bana ya da diğer ekip üyelerine sorduklarını fark ettim ve bu sorular teknik sorular değil, domain bazlı sorulardı. Örneğin, ürün data’sında ya da gönderilen event’lerde bulunan ancak domain’de tam olarak neye karşılık geldiği anlaşılamayan çok önemli birkaç alanın ne anlama geldiği; veya ekibin geliştirdiği bir öneri kutusunun tam olarak nasıl çalıştığı gibi sorular.

Ekipçe sorduğumuz soruların çoğu zaman aynı sorular olduğunu fark etmemle beraber, bu bilgi edinme işleminin daha efektif hale getirilebileceği düşünerek sorulan bu sorulara cevap olacak basit bir excel tablosu hazırlamaya başladım. Bu sorular domain ile ilgili sorular olduğundan da bu excel tablosu domain book adını aldı ve ekipçe önemli domainsel bilgilerle donatılmaya başlandı:

(bu ekran görüntüsünü koyabilmek için sütun sayısını hayli azaltmam ve description bölümündeki bilgileri temizlemem gerekti)

Hepsiburada’dan bir sene kadar önce ayrıldığım için bu excel tablosu şu an ne durumda pek bilmiyorum, ama ben ekipteyken de zaten “hevesli bir girişim” tadındaydı ve aktif olarak kullanılır duruma gelmemişti. Hepsiburada sonrasında da henüz bir başka domain book deneyimim olmadığından yazının devamında aklımdaki domain book’tan ve nelere çözüm olabileceğinden bahsetmek istedim. Haliyle aşağıda yazılanlar “sahada test edilmiş” değildir; hipotez aşamasındadır.

Domain book

Domain book basitçe, ekip içi bilgi aktarımının efektif hale gelmesini amaçlayan domainsel bilgi deposu olarak tanımlanabilir.

Örneğin, oryantasyon sürecinde, ekibe yeni katılan kişiyi genelde bir başka ekip üyesi (bu iş için görevlendirilen biri -ilk arkadaş- veya takım lideri, her kimse) karşılar ve domain hakkında -belki bir toplantı süresince- bilgilendirir; sorularına cevap verir. Ancak hem yapılan bu bilgilendirme kısıtlı bir bilgilendirme olduğundan, hem de bir doküman baz alınarak yapılmadığı için kesinlikle atlanan noktalar olacağından, bilgilendirme sonrasında yeni ekip üyesi uzun bir süre boyunca ekip arkadaşlarına çeşitli sorularla gelmeye devam eder. İşte tam da bu noktada domain book, sorulması muhtemel olan sorular için bir nevi “sıkça sorulan sorular” bölümü işlevi görür.

Domain book ile süreç şu şekilde işler: Ekibe yeni katılmış olsun-olmasın, aklına domain ile ilişkili herhangi bir şey takılan bir ekip üyesi (A), öncesinde aradığı bilgiyi domain book’ta bulmaya çalışır ve ancak bulamadığı durumda başka bir ekip üyesinin (B) yardımına başvurabilir. Bu noktadan sonra iki yol izlenebilir:

- A, B’den gerekli bilgiyi edindiği an domain book’u ilgili bilgiyle güncellemelidir.
- B, A’nın sorduğu soru sonrasında A’ya direkt olarak cevap vermek yerine domain book’u güncelleyip, A’yı domain book’u güncellediğine dair bilgilendirir.

İkinci yaklaşım, domain book’un güncellenmesinin unutulması ya da ihmal edilmesi ihtimallerini ortadan kaldırdığından daha tercih edilesi gibi duruyor. Hangi yol tercih edilirse edilsin, domain book, domain bazlı bilgi ediniminde başvurulacak ilk kaynak olmalı ve sürekli güncel kalmalıdır.

Domain üzerine bir dokümantasyon

Domain book sadece akla takılan sorular olduğu anlarda imdada koşan bir yardımcı değil, aynı zamanda domain’e dair bir çeşit dokümantasyon gibidir ve baştan sona okunduğunda okuyanın, özellikle yeni ekip üyelerinin domain’e aşina olmasını sağlar. Domain’e dair bilinmeyen çoğu nokta ortadan kalkar; her şey daha berrak hale gelir ve bu da normal olarak performansa olumlu yönde etki eder. Bu sebeple, ekibe katılan yeni üyelerden, aklına takılan bir soru olup olmamasından bağımsız olarak domain book’a göz atmaları beklenmelidir. Ekibe yeni katılan üyenin aklında, domain book’u okumasına rağmen hala bazı sorular kaldıysa -ya da yeni sorular oluştuysa- muhtemelen domain book güncellenmelidir. “Muhtemelen” diyorum, çünkü domain ile alakalı ve çok da kritik olsa da bazı bilgiler bir ihtimal yazıyla ifade edilmesi zor bilgiler olabilir ve bu tarz bilgilerin domain book’ta yer almaması tercih edilebilir.

”Bu neydi?” sözlüğü

Hepsiburada’da oryantasyon sürecim sonrasında dahi zaman zaman ekip arkadaşlarıma tekrar tekrar sormak durumunda kaldığım birkaç soru olmuştu. Bu yazının en başında da bahsettim: Domain’de neye karşılık geldiği sık sık karıştırılan çok önemli birkaç alanın tam olarak ne olduğunu soruyordum ve ekipte benden çok daha eski olan ekip arkadaşlarımla birlikte dahi bu soruları cevaplarken bir süre ikilemde kaldıktan sonra net cevaba ulaşabiliyorduk; çünkü bu neye tekabül ettiği ilk bakışta hiç anlaşılamayan alanların zamanla birbirine geçişmesi kaçınılmazdı ve ne olduklarını hatırlamak için zihinsel bir çaba sarf etmek gerekliydi.

Bir başka örnek: Hepsiburada’nın farklı farklı sayfaları için ekibin geliştirdiği çeşitli ürün öneri kutucuklarından birinin, tam olarak ne tür bir algoritmayla çalıştığını hatırlamaya çalışmadan tamamladığımız tek bir toplantı bile hatırlamıyorum.

Domain book işte bu gibi durumlarda, ekibin en eski, en deneyimli üyesinin bile sık sık başvurabileceği bir sözlük görevi görüyor ve toz tutmuş bilgiyi beynin ücra köşelerinde aramaya koyularak hem zaman, hem de zihinsel efor harcamak yerine çok daha iyi bir alternatif öneriyor. Toplantılar daha kısa sürüyor; ekip arkadaşları daha az rahatsız ediliyor.

Soruları cevaplamak artık daha keyifli

Ekibe yeni katılan üye çoğu zaman, ekip arkadaşlarını bitmek bilmeyen sorularıyla rahatsız etmek (!) durumunda kalır ve yine çoğu zaman bu sorular işine devam etmesini bloklayan sorulardır; yani rahatsız etmekte pekâlâ haklıdır. Elbette ekibinden ekibine değişir, ama zannediyorum ki çoğu ekipte bu sorulara hızlıca yanıt alabilmek pek mümkün değildir.

Ekip, bilgi aktarım aracı olarak domain book’u benimsemiş, kültürünün bir parçası haline getirmiş ise, ekibe yeni katılan üye ya da herhangi bir üye, domain book’ta sorusuna cevap bulamadığı durumda -soru gerçekten domain ile ilgiliyse- sorusuna anında cevap verilmesini “hak görebilir”; ilgili bilgiye domain book’ta ulaşamadığını söyleyerek ekip arkadaşlarından çok daha kolay şekilde yardım talebinde bulunabilir. Domain book’un bilgiyle donatılması ekibin tümünün asli sorumluluklarından biri olduğundan da, yeni ekip üyelerinin sorduğu soruların önemi artar; çünkü bir soruya verilen cevap artık, sadece tek bir üyeye fayda sağladıktan hemen sonra Slack’in tozlu mesajlaşma pencerelerinde kaybolup gitmek yerine, tüm ekip tarafından bilgi aktarım aracı olarak kullanılan bir mecraya kaydedilir ve aslında ekibin bir ürününe doğrudan katkıda bulunulmuş olunur. Domain book’suz bir dünyada her soru, ekibe yeni katılan her üye için tekrar tekrar cevaplanırken, domain book ile birlikte sadece bir kez domain book’a kaydedilir ve herkes mutlu olur; bilgi aktarımı çok daha keyifli hale gelir. Zamandan da büyük ölçüde tasarruf edilir.

İşe alışma sürecini her anlamda hızlandırma

Şimdiye kadar yazdıklarımdan anlaşılabileceği gibi domain book, ekibe yeni katılan kişinin alışma sürecinin her anlamda daha iyi hale gelmesine olanak sağlar. Daha önce yazdıklarım dışında örnek vermek gerekirse de, mesela, toplantılar domain terimleriyle doludur ve yeni ekip üyeleri için -toplantının ne tür bir toplantı olduğuna veya toplantıda kimlerin bulunduğuna bağlı olmakla da birlikte- toplantı akışını sık sık bölerek belirli terimlerin ne anlama geldiğini sormak çoğu zaman mümkün olmaz. Kendimden komik bir örnek vereyim: Hepsiburada’da her ekibin kendi belirlediği özel bir adı vardır ve ben ilk bir iki haftamı, toplantılarda ara ara geçen bir ekibin adını “Hepsiburada’nın geliştirdiği ve sadece şirket içinde kullanılan teknolojilerden biri” olduğunu düşünerek geçirmiştim. Haliyle, daha sonrasında domain book’a eklediğim ilk entity’lerden bazıları, yukarıdaki paylaştığım görselde de görülebileceği üzere ekiplerin isimleri ve hangi domain’den sorumlu oldukları oldu.

Özetle, sürekli elin altında bulundurulan (yani, yan sekmede açık duran) bir domain book, karşılaşılan ve ne olduğu bilinmeyen terimlerin hızlıca öğrenilmesine de olanak sağlar; ekibe yeni katılan üyeler için toplantıların bazı anlarını bir bilinmezlik olmaktan çıkarıp, toplantıların çok daha faydalı hale gelmesine yol açabilir.

Domain book’a başlamak ve güncel tutmak

Kendi ekibiniz için bir domain book yaratmak çok kolay; size bir soru geldiğinde ya da siz bir soru sorduğunuzda, bu sorunun gelecek zamanda başka bir ekip üyesi tarafından -ya da bizzat sizin tarafınızdan- bir daha sorulabileceği düşüncesindeyseniz soruyu ve cevabını bir excel tablosuna ya da tüm ekibin ulaşabildiği herhangi bir dokümana not almak ve mümkünse not alınan bu bilgileri uygun bir biçimde kategorize etmek yeterli. Kategorize etmek şunun için önemli: Domain book’a eklenecek bilgi domain üzerine genel bir soru-cevap da olabilir, toplantılarda sıkça duyulan bir terimin ne demek olduğu da olabilir, mimaride kıyıda köşede kalmış bir servisin tam olarak ne işlev gördüğü de olabilir. Bu tür bilgileri gruplamak kullanım kolaylığı sağlar.

Domain book’u güncel tutmak için ise, ekip içi bilgi aktarımı için -yazının başlarında ifade ettiğim biçimde- domain book’u esas almak elzem. Zaten bunun yapılmadığı durumda tüm çaba boşa gitmiş demektir. Ve ek olarak, her işin definition of done maddeleri arasına “gerekli ise domain book’u güncellenmeli” maddesi eklenmelidir, çünkü tamamlanan işlerden bazıları aynı zamanda domain’e bir katkı.

Sonuç

Domain book, “soru soran ve soruyu cevaplayan” ikiliğinde soruyu cevaplayanın yerini alarak insana bağımlılığı azaltır ve bilgi aktarımını bir biçimde otomatize hale getirir; daha verimli bir hal almasını amaçlar. Soru soranın, cevabına çok daha kısa sürede ulaşmasını; soru cevaplayanın ise hem zamandan tasarruf etmesini, hem de sık sık context switching’e maruz kalmaktan kurtulmasını sağlar. Yani, öyle umuyorum.

Aslında domain book’un, en başta söylediğim gibi Hepsiburada’dayken bir excel tablosunun oluşturulmasıyla değil de onun çok az öncesinde ortaya çıktığı söylenebilir: “Ekip arkadaşlarıma tekrar tekrar sordum” dediğim soruların cevaplarını not alıp bir noktada toplamaya başladıktan sonra, bir ekip arkadaşımın bana sorduğu soruyu yanıtlamak için aynı notlara bakmam gerektiğinde fark etmiştim ki, benim kişisel notlarımda bulunan çoğu bilgi aslında kişisel değil, ekipsel bilgi. Böyle bir ortak not defterine sahip olmanın önemi yalnızca bu örnekten anlaşılabilir sanıyorum. Ekipteki bir junior üyenin, kısa bir araştırmayla cevabını bulabileceği teknik bir soruyu, araştırmak yerine ekibinden bir arkadaşına sormasını hiç hoş karşılamıyoruz çünkü elimizin altında teknik sorularımıza cevap bulabileceğimiz bir Google, bir Stackoverflow var. Ancak domain ile alakalı sorularımıza cevap bulabileceğimiz bir mecra yok-tu, domain book’a kadar.

Domain book fikri aslında benim için basit bir excel tablosundan ya da dengi bir dokümandan ibaret değil (ki zaten “fikir” olan kısım domainsel bilgileri tek bir noktada toplamak değil; ekip içi bilgi aktarımını doğrudan bir başkasına sormak yerine araya bir temsilci koyarak gerçekleştirmek). Bu fikrin, domain book‘u müşterilerine bir ürün olarak sunan bir SaaS olarak hayata geçirilebileceği ve DDD dünyasında bir ihtimal dikkat çekebileceği düşüncesindeydim ama buna uzunca bir süre vakit bulamayacağımı düşündüğümden “aklımda duracağına Medium’da dursun” düşüncesiyle böyle bir yazı yazmak istedim. Zaten bir başka yazıda da bu ürünün tüm feature’larından bahsedip bu SaaS fikrini başkasına altın tepside sunma niyetim var.

(Twitter’ı sadece yazdığım yazıları paylaşmak için kullanıyorum; yeni yazılardan haberdar olmak için takip edebilirsiniz)