Karmaşık iş kurallarına sahip bir kurumsal yazılım projesinde en sık karşılaşılan sorun, kod yapısının iş mantığını doğru yansıtmamasıdır. Zamanla farklı ekiplerin farklı anlamlar yüklediği kavramlar, birbiriyle çelişen modüller ve bakımı giderek zorlaşan bir kod tabanı ortaya çıkar. Domain Driven Design, tam olarak bu sorunu çözmek için Eric Evans tarafından ortaya konmuş bir yazılım tasarım yaklaşımıdır. Bu rehberde DDD’nin temel kavramlarını, bounded context ve event storming tekniklerini ve mikroservis mimarisiyle ilişkisini ele alıyoruz.
Domain Driven Design Nedir?
Domain Driven Design, yazılımın teknik yapısını iş alanının (domain) gerçek mantığı etrafında şekillendiren bir tasarım felsefesidir. DDD’nin temel önermesi, geliştiricilerin ve iş birimi uzmanlarının ortak bir dil (ubiquitous language) üzerinden konuşması ve bu ortak dilin doğrudan kod yapısına yansımasıdır. Bu yaklaşım, “sipariş” kavramının pazarlama ekibi için ve muhasebe ekibi için farklı anlamlar taşıyabileceği gerçeğini kabul eder ve bu farklılığı kodda açıkça modellemeyi hedefler.
Stratejik DDD: Bounded Context
Bounded context, bir iş kavramının belirli bir sınır içinde tek ve tutarlı bir anlama sahip olduğu alanı tanımlar. Örneğin bir e ticaret sisteminde “ürün” kavramı, envanter yönetimi bağlamında stok miktarı ve depo konumuyla; pazarlama bağlamında ise açıklama metni ve görsel içerikle tanımlanır. Bu iki bağlamı tek bir dev modelde birleştirmeye çalışmak, zamanla yönetilemez bir karmaşıklık yaratır. Bounded context, bu iki alanı bilinçli olarak ayırarak her birinin kendi iç tutarlılığını korumasını sağlar.
Bounded context’ler arasındaki ilişki context map adı verilen bir diyagramla görselleştirilir. Bu harita, hangi bağlamın hangi bağlama veri sağladığını, hangi bağlamların birbirinden bağımsız evrilebileceğini netleştirir ve mimari kararların iş gereksinimleriyle uyumlu ilerlemesini sağlar.
Bounded context sınırlarının mikroservis mimarisine nasıl yansıdığı hakkında microservices nedir, .NET microservices nasıl çalışır yazımızı inceleyebilirsiniz.
Event Storming: Domain’i Keşfetme Yöntemi
Event storming, iş birimi uzmanları ile geliştiricilerin bir araya gelerek bir iş sürecindeki tüm önemli olayları (domain event) renkli yapışkan notlarla bir zaman çizelgesi üzerinde haritalandırdığı işbirlikçi bir atölye yöntemidir. “Sipariş oluşturuldu”, “ödeme onaylandı”, “kargo hazırlandı” gibi geçmiş zamanlı olaylar sırayla dizilerek sürecin uçtan uca akışı görselleştirilir.
Bu yöntemin en büyük değeri, teknik olmayan paydaşların da sürece aktif katılabilmesidir. Geliştiriciler tek başına domain modelini tahmin etmek yerine, iş birimi uzmanlarının gerçek süreç bilgisinden doğrudan faydalanır. Event storming oturumları genellikle bounded context sınırlarının doğal olarak ortaya çıkmasını sağlar; bir grup olay birbiriyle yoğun etkileşim içindeyken başka bir grup olaydan belirgin biçimde ayrışıyorsa, bu ayrışma potansiyel bir bounded context sınırına işaret eder.
Taktiksel DDD: Temel Yapı Taşları
Entity:
Zaman içinde durumu değişse bile kimliğiyle tanımlanan nesnelerdir; bir müşteri kaydı, adresi değişse bile aynı entity olarak kalır.
Value Object:
Kimliği olmayan, yalnızca değeriyle tanımlanan nesnelerdir; bir para tutarı veya adres bilgisi bu kategoriye girer.
Aggregate:
Birlikte tutarlı kalması gereken entity ve value object gruplarını, tek bir kök nesne (aggregate root) üzerinden dışarıya kapalı biçimde yöneten yapıdır. Aggregate, veri tutarlılığının korunduğu en küçük işlemsel birimdir.
Domain Event:
Sistemde gerçekleşmiş ve diğer bileşenlerin haberdar olması gereken önemli bir iş olayını temsil eder; mikroservisler arası asenkron iletişimin temel yapı taşlarından biridir.
DDD ve Mikroservis Mimarisi İlişkisi
DDD, mikroservis mimarisinin zorunlu bir ön koşulu değildir; ancak iyi tanımlanmış bounded context’ler, mikroservis sınırlarını belirlemek için doğal ve sağlam bir temel sunar. Her mikroservisin bir bounded context’e karşılık gelmesi, servisler arası bağımlılığı azaltır ve her ekibin kendi servisini bağımsız biçimde geliştirip dağıtabilmesini sağlar. DDD uygulanmadan doğrudan mikroservis mimarisine geçen ekipler, sıklıkla “dağıtık monolit” adı verilen; teknik olarak ayrılmış ama iş mantığı açısından hâlâ sıkı sıkıya bağlı bir yapıyla karşılaşır.
Kod tabanının uzun vadeli sürdürülebilirliği için temiz kod prensipleri de DDD ile birlikte değerlendirilmelidir; bu konuda clean code nedir, clean code ile refactoring nasıl yapılır yazımızı inceleyebilirsiniz.
DDD Uygularken Sık Yapılan Hatalar
En yaygın hata, DDD’yi yalnızca teknik bir katman yapısı (controller, service, repository) olarak algılamaktır; oysa DDD’nin özü stratejik tasarımda, yani domain’in doğru sınırlarla ayrıştırılmasında yatar. Bir diğer sık hata, her projeye aynı yoğunlukta DDD uygulamaya çalışmaktır; basit CRUD işlemlerinden oluşan düşük karmaşıklıktaki bir modül için tam kapsamlı taktiksel DDD uygulamak, gereksiz karmaşıklık yaratabilir. DDD, karmaşık iş kurallarına sahip domain’lerde en yüksek katma değeri sağlar.
Kurumsal yazılım mimarisinde kullanılan diğer tasarım desenleri için kurumsal yazılım mimarisi tasarım desenleri yazımızı da inceleyebilirsiniz.
Kimler DDD Öğrenmeli?
Yazılım mimarları, kıdemli backend geliştiriciler ve teknik liderler DDD’den doğrudan yararlanır. Özellikle karmaşık iş kurallarına sahip bankacılık, sigortacılık, lojistik ve kurumsal kaynak planlama sistemleriyle çalışan ekipler için DDD, uzun vadeli bakım maliyetini önemli ölçüde azaltan stratejik bir yatırımdır.
Bounded context, event storming ve mikroservis mimarisini uygulamalı atölye çalışmalarıyla öğrenmek için BlueMark Academy Domain Driven Design (DDD) eğitimini inceleyebilirsiniz. Beş günlük yoğun program, stratejik ve taktiksel DDD’yi gerçek kodlama atölyeleriyle birleştirmektedir.
Sıkça Sorulan Sorular
DDD her projede uygulanmalı mıdır?
Hayır. Basit, düşük karmaşıklıktaki projelerde DDD’nin getirdiği ek yapı gereksiz maliyet yaratabilir. DDD, iş kurallarının karmaşık ve sık değişken olduğu domain’lerde en yüksek değeri sağlar.
Event storming için özel bir yazılım gerekir mi?
Hayır. Geleneksel event storming fiziksel yapışkan notlar ve geniş bir duvarla yapılabilir; uzaktan çalışan ekipler için Miro veya FigJam gibi dijital pano araçları da yaygın olarak kullanılmaktadır.
DDD öğrenmek için hangi ön bilgi gereklidir?
Nesne yönelimli programlama temellerine ve orta düzey yazılım geliştirme deneyimine sahip olmak, DDD kavramlarını pratik projelere uygulayabilmek için önerilen bir başlangıç seviyesidir.