Domain-Driven Design'a Giriş: Neden ve Nasıl?

Domain-Driven Design (DDD), ilk duyduğumda bana gereksiz karmaşık bir akademik kavram gibi gelmişti. Gerçek projelerde iş kurallarının karmaşıklaştığı noktalarda uyguladıkça, aslında çok pratik bir düşünme biçimi olduğunu gördüm.

Anemic Model'in Sorunu

Çoğu projede entity'ler sadece property'lerden oluşan, hiçbir davranışı olmayan "anemic" (kansız) modeller olarak yazılıyor; tüm iş mantığı servis sınıflarında topluca duruyor. DDD'nin ilk önerdiği değişiklik, iş kurallarını entity'lerin kendisine taşımak: bir Order nesnesi, kendi geçerliliğini kendisi kontrol etmeli.

public class Order
{
    private readonly List<OrderItem> _items = new();
    public void AddItem(Product product, int quantity)
    {
        if (quantity <= 0)
            throw new ArgumentException("Miktar sıfırdan büyük olmalı");
        _items.Add(new OrderItem(product, quantity));
    }
}

Value Object'ler: Kimliksiz Ama Anlamlı Veriler

Bir adres ya da para birimi gibi kavramları basit string/decimal yerine, kendi doğrulama mantığını taşıyan Value Object'ler olarak modellemek, geçersiz durumların sisteme sızmasını engelliyor. Money tipi negatif bir değeri baştan reddedebiliyor, bu kontrolü her yerde tekrar tekrar yazmama gerek kalmıyor.

Aggregate: Tutarlılık Sınırını Çizmek

Bir Order ve onun OrderItem'ları birlikte bir "aggregate" oluşturuyor: dışarıdan sadece Order üzerinden erişilebiliyor, OrderItem'lara doğrudan müdahale edilemiyor. Bu sınır, verinin her zaman tutarlı bir durumda kalmasını garanti ediyor.

Ubiquitous Language: Ortak Dil

DDD'nin bence en az teknik ama en değerli tarafı, iş birimiyle geliştiricilerin aynı terimleri kullanması. Kodda ProcessOrder() yerine iş biriminin kullandığı "Siparişi Onayla" ifadesine karşılık gelen ConfirmOrder() gibi isimler kullanmak, kod ile gerçek dünya arasındaki mesafeyi azaltıyor.

Ne Zaman Gerekli, Ne Zaman Fazla?

Basit CRUD ağırlıklı bir projede DDD'nin tüm kavramlarını (aggregate, domain event, bounded context) uygulamak gereksiz karmaşıklık katıyor. Bu yatırımı, gerçekten karmaşık iş kurallarının olduğu, uzun ömürlü projelerde yapıyorum.

Sonuç

DDD bana bir framework değil, bir düşünme biçimi kazandırdı: iş mantığını teknik detaylardan koruyup, kodun iş biriminin diliyle konuşmasını sağlamak. Bu, özellikle karmaşık domain'lerde uzun vadede büyük fark yaratıyor.