Domain Driven Design (DDD) ile Sağlam Yapılar Kurmak

Modern yazılım projelerinde kodun teknik olarak kusursuz olması kadar, iş ihtiyaçlarını doğru modelleyebilmesi de büyük önem taşır. İşte tam bu noktada Domain Driven Design (DDD) devreye girer. Eric Evans’ın 2003 yılında ortaya koyduğu bu yaklaşım, karmaşık yazılım sistemlerinin işe uygun, sürdürülebilir ve esnek şekilde inşa edilmesini amaçlar.

Peki, DDD tam olarak nedir ve neden bu kadar önemlidir?

🧠 DDD Nedir?

Domain Driven Design, yazılım sistemini geliştirirken odağa iş alanını (domain) koyan bir yaklaşımdır. Temel amacı, yazılımın iş kurallarına birebir karşılık gelmesini sağlamaktır. Bunu başarmak için teknik ekip ile iş birimi arasında ortak bir dil (ubiquitous language) oluşturulur.

🔍 Temel Kavramlar

1. Domain (Alan Bilgisi)

İşletmenin faaliyet gösterdiği alan. Örneğin bir muhasebe yazılımında “fatura”, “muhasebe kaydı”, “kasa hareketi” gibi kavramlar domain’e girer.

2. Entity (Varlık)

Kimliği olan nesnelerdir. Örneğin bir Kullanıcı nesnesi, ID’siyle benzersiz şekilde tanımlanır.

3. Value Object (Değer Nesnesi)

Kimliği olmayan, sadece değeri önemli olan nesnelerdir. Örneğin bir Adres veya Para nesnesi.

4. Aggregate (Küme)

İlgili entity ve value object’lerin oluşturduğu, bütüncül olarak yönetilen yapıdır.

5. Repository

Veritabanı gibi dış kaynaklarla iletişimi soyutlayan katmandır. Bir aggregate’e erişim bu katmandan sağlanır.

6. Bounded Context (Sınırlandırılmış Bağlam)

Bir kavramın belirli bir bağlamda belirli bir anlama gelmesini sağlayan yapıdır. Örneğin “Kullanıcı” kavramı bir e-ticaret sisteminde hem müşteri hem yönetici anlamına gelebilir, ama farklı bounded context’lerde farklı davranışlar gösterir.

🏗️ Neden DDD?

• İş birimi ile geliştirici arasındaki iletişimi güçlendirir.
• Kodun anlaşılabilirliğini ve sürdürülebilirliğini artırır.
• Büyük sistemleri küçük, yönetilebilir parçalara ayırarak kompleksliği azaltır.
• Sistemin gelecekteki gelişmelere açık ve esnek olmasını sağlar.

🛠️ DDD Ne Zaman Kullanılmalı?

DDD, karmaşık iş kurallarına sahip projelerde büyük fayda sağlar. Ancak her projeye uygulanması şart değildir. Eğer projenin iş kuralları basitse ya da sadece veri giriş-çıkış işlemleri yapılıyorsa, DDD gereksiz karmaşıklık yaratabilir.

Kullanılması gereken durumlar:

• İş kurallarının çok katmanlı ve değişken olduğu projeler
• Sürekli gelişen büyük ölçekli sistemler
• Farklı domain uzmanlarının dahil olduğu yapılar

🛒 E-Ticaret Platformu Örneği

Domain: Sipariş Yönetimi

Bounded Context:

• Müşteri Yönetimi
• Ürün Kataloğu
• Sipariş ve Ödeme
• Kargo Takibi

Entity & Value Object:

• Müşteri (Entity): ID, isim, e-posta
• Sipariş (Entity): sipariş numarası, müşteri ID, ürün listesi
• Adres (Value Object): şehir, ilçe, açık adres

Açıklama:

E-ticaret sistemlerinde “kullanıcı” kavramı müşteri yönetiminde farklı, ödeme sisteminde farklı anlamlar taşır. Bu nedenle her bir bounded context kendi domain modelini içerir. Bu yapı sayesinde her ekip kendi bounded context’inde bağımsız geliştirme yapabilir.

🧾 Finans Uygulaması Örneği

Domain: Muhasebe ve Bütçe Takibi

Bounded Context:

• Fatura İşleme
• Gelir-Gider Raporlama
• Banka Entegrasyonu

Entity & Value Object:

• Fatura (Entity): fatura no, müşteri ID, tutar, tarih
• Para (Value Object): değer, döviz cinsi
• BankaHesabi (Entity): IBAN, banka adı

Açıklama:

Muhasebe sistemlerinde, bir “ödeme” işlemi hem banka tarafında hem muhasebe tarafında farklı anlamlara gelir. DDD ile bu ayrımı net bir şekilde yapabilir ve domain mantığını her bağlamda doğru şekilde işleyebiliriz.

🧑‍⚕️ Sağlık Sektörü Örneği

Domain: Hasta Takibi ve Tedavi Süreci

Bounded Context:

• Hasta Kayıt ve Randevu
• Tedavi Planı
• Reçete ve Eczane

Entity & Value Object:

• Hasta (Entity): TC no, ad soyad, doğum tarihi
• Randevu (Entity): doktor, tarih, poliklinik
• İlaçDozu (Value Object): miktar, birim, sıklık

Açıklama:

Bir “hastanın” bilgileri hasta kayıt sisteminde kimlik bilgileriyle temsil edilirken, reçete sisteminde sağlık geçmişiyle ilişkilidir. Bu tür sistemlerde DDD, iş kurallarının net ayrımı sayesinde hata riskini azaltır ve modülerlik kazandırır.

📦 Lojistik & Depo Yönetimi Örneği

Domain: Envanter ve Sevkiyat

Bounded Context:

• Depo Yönetimi
• Sevkiyat Planlama
• Tedarikçi Takibi

Entity & Value Object:

• Ürün (Entity): barkod, stok kodu, miktar
• Lokasyon (Value Object): raf numarası, depo alanı
• Sevkiyat (Entity): araç plakası, çıkış saati

Açıklama:

Bir ürün, depo yönetiminde sadece stok anlamına gelirken, sevkiyat modülünde taşıma detaylarıyla ilgilidir. Bounded context’ler bu ayrımı kolaylaştırır, ekiplerin iş bölümü yapmasını sağlar.

Bu örneklerde görüldüğü gibi DDD, iş kurallarının ayrıştırılması, ekipler arası sorumlulukların netleştirilmesi ve kodun daha sürdürülebilir hale gelmesi için oldukça güçlü bir yaklaşımdır.

🤝 DinamikUp Yorumu

DinamikUp olarak birçok projede Domain Driven Design yaklaşımını uyguluyor ve bu yöntemle daha sağlam, ölçeklenebilir ve anlaşılabilir yapılar kuruyoruz. DDD sadece bir yazılım metodolojisi değil, aynı zamanda daha sağlıklı iletişim kurma ve iş dünyasının dinamiklerine uyum sağlama biçimidir. Özellikle mikroservis mimarisiyle birlikte kullanıldığında büyük bir sinerji yaratır.

🔖 Etiketler

#DomainDrivenDesign, #DDD, #YazılımMimarisi, #BoundedContext, #Entity, #ValueObject, #CleanArchitecture, #DinamikUp,