DDD ve Mikroservis Kavramları Üzerine — Bounded Context

DDD ve Mikroservis Kavramları Üzerine — Bounded Context

Geleneksel iş yapma biçimlerinin yerini, rekabetçi ve yenilikçi teknolojik çözümlere bırakması ile birlikte şirketlerin iş süreçlerinin dijitalleşmesi gerekliliği ortaya çıktı. Bununla beraber şirketlerin teknoloji departmanlarına yatırım yapması kaçınılmazdı ancak hızlı büyüyen teknoloji ekiplerinin tek merkezli ( monolith ) uygulamalar üzerindeki hakimiyeti günden güne zorlaşıyor, code-base’ler kontrolden çıkacak şekilde büyüyordu. Bu da şirketleri ölçeklenebilirlikten , test ve refactor edilebilirlikten uzaklaşmış yazılım sistemleri ile baş başa bırakmıştı. Bu durum firmaların değişen iş ihtiyaçlarına hızlı adapte olmama problemi ile yüzleşmesine neden oldu. Gelişime dirençli ve yüksek maliyetli yazılım sistemleri, firmaları rekabette epeyce geriye düşürüyordu. Bazı büyük teknoloji firmalarının önderliğinde, büyük uygulamaları farklı küçük servislere ayrıştıran service oriented architecture (SOA) yaklaşımı ortaya atıldı. Bu, büyük bir yazılım projesini daha iyi yönetilebilir küçük parçalara bölmeye dayalı mimarisel bir çözümdü. Ancak SOA, takip eden yıllarda yerini, kendi başına deploy edilebilen ( fine grained ), birbirine zayıf bağımlılıklara bağlı ( loosly coupled ) servislerden oluşan mikroservis yaklaşımına evrildi.

Bu yaklaşımla hedeflenen;

• Kolay yönetilebilir (light weight) code-base’e sahip olmak
• Test edilebilirliği (testibility) arttırmak,
• Ölçeklenebilirliği (scalability) arttırmak,
• Esnekliği (felxibility) arttırmak,
• Yüksek erişilebilirliği (highly availability) sağlamak,
• Yeni özellikleri hızlıca release edebilmek (time to market),
• Organizasyonel yapı ile yazılım sistemi arasındaki uyumu sağlamaktı.

Mikroservis yaklaşımı ile birlikte “teoride” yüzlerce yazılım mühendisi aynı projenin farklı modüllerinde paralel olarak çalışabilir, servisler birbirinden bağımsız olarak deploy edebilebiir, uygulamaların farklı modülleri farklı stratejiler ile ölçeklendirilebilir ve yeni bir gereksinim oluştuğunda sistemin küçük bir parçasında yapılan değişiklik ile iş gereksinimleri pazara çok hızlı bir şekilde çıkabilir. Ancak, kulağa hoş gelen bu değerleri üretebilmek için büyük ekiplerin, iş kuralları ve teknolojik gereksinimleri konusunda, nasıl organize olacağına dair bir sistematiğe, fikir birliğine ve ortak bir iletişim diline sahip olması gerekir. İşte tam burada domain driven design (DDD) disiplini yazılım mühendislerine yeni yöntemler sunuyor.

Domain Driven Design (DDD)?

Bu kavramı anlamak için öncelikle “domain nedir” sorusuna güvenilebilir bir cevap vermek gerekir. Yazılımları gerçek dünya problemlerine çözüm üreten ve tekrar tekrar kullanılabilen makina prosedürleri olarak tanımlayabiliriz. Bahsettiğimiz bu “gerçek dünya problemi”’nin çözümüne dair bilgi birikimine domain yani etki alanı denir. Örneğin bir ürünün, internet üzerinden en hızlı şekilde ve en uygun fiyat ile tüketiciye ulaştırılabilmesi problemi e-ticaret domainine ait bir problemdir. DDD ise bu bilgi birikimini daha çok açığa çıkararak, karmaşık domain probleminin çözümünü belli bir sistematiğe göre yazılımsal olarak modellemeyi sağlayan bir disiplindir.

Yüksek işbirliğine ihtiyaç duyulan ve doğası gereği belli bir karmaşıklık barındıran etki alanlarına collaborative domain denmektedir. Genel olarak, DDD’nin bu karakteristiğe ait domain’ler için daha uygun bir çözüm olduğu kanısı hakimdir.

DDD’nin stratejik ve taktiksel olmak üzere iki ayrı aşaması vardır. Stratejik DDD’de, iş kurallarına bağlı kalarak sistemin büyük ölçekli modelini tanımlarız. Stratejik DDD, birbirine gevşek bağlı birimleri ( bounded context ) ve bunlar arasındaki ilişkiyi ( context map ) tasarlamayı sağlayan disiplinleri belirler. Taktik DDD, implementasyona odaklanır ve yazılımsal implementasyonu oluşturmak için kullanabileceğimiz tasarım desenlerini sağlar. Bu tasarım desenleri entity, aggregate, value object, repository ve domain service gibi kavramları içerir (ki bu yazıda taktik patternlerin detayına girmeyeceğiz — bunla ilgili başka bir post yayınlamayı düşünüyorum).

DDD’nin üretttiği en önemli değer değişen iş kuralları üzerinde ortak bir dil oluşturarak büyük teknoloji ekipleri arasındaki iş birliğini ( collobration ) arttırmaktır. DDD domaini kendine ait ortak bir dil barındıran, sınırları belirli, bağımsız bileşenlere ayıran bir yaklaşımı belirler. Oluşan bu ortak dile ubiquitous language, bağımsız birimlere ise bounded context denir. Bounded context DDD için modelleme açısından en önemli kavramlardan biridir ve DDD ile ilgili kaynaklarda sıkça karşılaşacağımız bir kavramdır. Gelin bunu detaylandıralım.

Bounded Context?

Karmaşık bir problemin çözümünden uyguladığımız yöntem, genellikle problemi daha küçük parçalara bölmek ve nispeten daha kolay olan bu küçük problemlere odaklanmaktır. Bounded context için karmaşık domain’in -kendi içinde tutarlı ve mümkün olduğunca bağımsız- daha küçük problem parçacıklarını temsil eden mantıksal sınırlardır (logical boundry) diyebiliriz. DDD’nin stratejik design başlığı altında yer alır ve bu yönüyle modelleme evresinde ortaya çıkan bir kavramdır. Contextler belirlenirken birbirine daha az bağımlı, birbirinden izole ve herbirinin otonom olması gibi değerler önceliklidir.

Bounded Context sınırlarını nasıl belirleriz?

Bounded context’lerin belirlenmesi konusu DDD’nin stratejik tasarım ( strategic design ) evresini ilgilendiren bir konudur. Stratejik tasarım evresi modelleme işnin yapıldığı süreçtir ve implementasyondan bağımsız bir konudur.

Bu süreç çoğu kaynakta context discovery olarak belirtilir. Dolayısı ile bir keşif serüvenidir diyebiliriz. Bu yönüyle baktığımızda, context boundary’lerin reçetesi veya nokta atışı bir yöntemi olduğundan bahsedemeyiz. Bu konuyla ilgili olarak çoğu DDD mecrasında heuristic ifadesini görebilirsiniz. Bu, hissiyati ya da içgüdüsel anlamına gelir. Yani bu süreç, business ihtiyaçları, modellemeyi yapan insanlar, teknik kısıtlar, ekip içi iletişim gibi bir sürü parametreye bağlıdır. Ancak, modelleme sürecinin tamamı ile belirsiz bir hal almaması için DDD dünyası bazı önemli konulara işaret eder.

Domain knowledge (Domain yetkinliği): Doğru bir model için önce problemin doğru anlaşılması ve analiz edilmesi gerekir. Ayrıca, farklı domainler kendine has iş kuralları barındırır. Bu kuralları doğru anlamak, saklı olanları da açığa çıkarabilmek için işbirliği ve iterasyon büyük önem taşır.

Collobration (İşbirliği): Doğru modeli bize hazır halde sunan bir araç olmadığına göre, bu süreç insanlar tarafından yürütülecektir. Doğru model için daha fazla domain knowledege, bunun için de farklı bakış açısı ve vizyonlar gerekir. Ancak bu durum modelleme sürecine her önümüze geleni dahil edeceğimiz anlamına gelmez. Etkili bir model için sürecin domain uzmanları ( domain expert ) tarafından yönlendirilmesi önemlidir. Domain expert kavramı bir rol ya da title değildir. Problemi çok iyi anlamış hatta o problemi yaşayan biri olabilir. Buradan yola çıkarak domain expert olarak en iyi örnek aslında müşterinin ta kendisidir diyebiliriz.

Iteration (Tekerrür): Modellemenin bir keşif serüveni olduğundan bahsettik. Ancak bu keşif mükemmeli aramak değildir. Mükemmel modeli aramaktansa, modelimizdeki eksikleri zaman içerisinde iyileştirmek, ürünün pazara daha hızlı çıkması açısından ( time to market ) akılcı bir yaklaşımdır. Gelişen pazar koşullarına bağlı iş kurallarının da sürekli değiştiğini hesaba katarsak, modelin bir kere belirlendikten sonra, bir daha asla değişmeyeceğinden bahsedemeyiz. Domain uzmanları ile iletişim içerisinde modelimizi sürekli geliştirmeliyiz. Teknik bakış açısıyla DDD’nin continuous refactoring ve continuous delivery konularına da dokunduğundan bahsedebiliriz.

Diğer bir önemli etken de organizasyondur. Sistemleri yapanlar organizasyonlardır ve iletişim alışkanlıkları yaptıkları çözüme yansır (bkz. Conway’s law). Bu duruma kanıt olarak, benzer işi yapan iki farklı şirkete baktığımızda, aynı problemi çözüyor olsalar bile yazılımsal modelin farklılıklar gösterdiğini görebiliriz.

Sonuç

• DDD, kompleks domainlerde uygulandığında fayda üreten bir pratiktir.
• DDD’nin strategic design evresinde domain knowledge, doğru modelleme için büyük önem taşır.
• Domain knowledge açığa çıkarmak için domain expertler ile birlikte çalışmak gerekir.
• DDD, collobrative bir yöntemdir domain expertler ve teknik ekipler arasında güçlü bir iletişim sağlanmalıdır.
• DDD, mikroservis gibi mimarisel yaklaşımlarda yönlendirici olabilir ancak belirleyici unsur değildir. Servis sınırları teknik concernler öncelenerek oluşturulur.

Yazının devamı — DDD ve Mikroservis Kavramları Üzerine — Bounded Context Mikroservis İlişkisi ve Tutarlılık