Uma Abordagem Funcional para Domain-Driven Design

Modern yazılım geliştirme dünyasında, iş dünyasının karmaşık ve sürekli değişen gereksinimlerini karşılamak, mimarlar ve geliştiriciler için sürekli bir meydan okumadır. Bir yandan iş alanının derinlemesine anlaşılması ve bu anlayışın kod tabanına doğru bir şekilde yansıtılması gerekirken, diğer yandan yazılımın test edilebilir, bakımı kolay ve ölçeklenebilir olması hedeflenir. Geleneksel nesne yönelimli yaklaşımlar, özellikle büyük ve karmaşık sistemlerde, yan etkiler, durum yönetimi zorlukları ve değişen gereksinimlere uyum sağlama konusunda bazen yetersiz kalabilir. Peki, iş alanının kalbinden doğan güçlü bir tasarım felsefesi olan Domain-Driven Design (DDD) ile, yan etkileri en aza indiren ve öngörülebilirliği artıran Fonksiyonel Programlama (FP) prensiplerini birleştirerek daha sağlam ve esnek sistemler inşa etmek mümkün müdür?

Domain-Driven Design, yazılımı iş alanının temelini ve karmaşıklığını yansıtacak şekilde yapılandırmaya odaklanan bir yazılım geliştirme yaklaşımıdır. Eric Evans tarafından 2003 yılında tanıtılan bu felsefe, özellikle karmaşık iş alanlarına sahip uygulamalarda, geliştiricilerin ve iş birimlerinin aynı dili konuşmasını (Ubiquitous Language) sağlamayı, böylece yanlış anlaşılmaları ortadan kaldırmayı hedefler. Temel olarak, yazılımı oluştururken, çözümü değil, problemi (yani iş alanını) merkeze alırız. Bu yaklaşım, yazılımın sadece teknik bir çözüm olmaktan öte, iş değeri üreten ve işin kendisiyle birlikte evrilen canlı bir yapı olmasını sağlar.

DDD’nin temel taşları arasında Varlıklar (Entities), Değer Nesneleri (Value Objects) ve Aggregate’ler bulunur. Varlıklar, yaşam döngüsü ve benzersiz bir kimliği olan nesnelerdir (örneğin, bir Müşteri veya bir Sipariş). Değer Nesneleri ise benzersiz bir kimliği olmayan, değerleriyle tanımlanan ve genellikle değişmez olan nesnelerdir (örneğin, bir Adres veya bir Para Birimi). Aggregate’ler ise, tutarlılığı korumak için bir arada ele alınması gereken Varlıklar ve Değer Nesnelerinin bir kümesidir ve her Aggregate’in bir Aggregate Kökü (Aggregate Root) bulunur. Bu kök, Aggregate içindeki diğer tüm nesnelere erişim kapısıdır ve Aggregate’in tutarlılığını sağlamaktan sorumludur. Örneğin, bir “Sipariş” Aggregate’i, “Sipariş” Varlığı (kök), “Sipariş Kalemleri” Varlıkları ve “Adres” Değer Nesnelerini içerebilir.

Ayrıca, DDD’de Sınırlı Bağlamlar (Bounded Contexts) kavramı çok önemlidir. Bu kavram, büyük bir sistemin farklı bölümlerinin kendi içinde tutarlı bir dil ve model setine sahip olduğunu belirtir. Örneğin, bir e-ticaret sisteminde “Ürün Kataloğu” bağlamındaki bir “Ürün” ile “Sipariş Yönetimi” bağlamındaki bir “Ürün” farklı özelliklere ve davranışlara sahip olabilir. Bu ayrım, her bir bağlamın kendi içinde karmaşıklığını yönetmesini kolaylaştırır ve tüm sistemi tek bir monolitik modele dönüştürme hatasından kaçınmamızı sağlar. DDD, iş kurallarını açıkça ifade eden ve yan etkileri kontrol altına alan Domain Servisleri (Domain Services) ve iş alanındaki olayları temsil eden Domain Olayları (Domain Events) gibi yapılarla zenginleşir. Tüm bu yapılar, yazılımın iş mantığını daha şeffaf, test edilebilir ve sürdürülebilir hale getirmesine yardımcı olur. Ancak, geleneksel nesne yönelimli paradigmalarla bu prensipleri uygularken, özellikle mutasyon (durum değişimi) ve yan etkilerle başa çıkmak zorlayıcı olabilir. İşte bu noktada Fonksiyonel Programlama devreye girer.

Fonksiyonel Programlama (FP) Temelleri: Temiz Kodun ve Öngörülebilirliğin Sırrı mı?

Fonksiyonel Programlama, yazılım geliştirmeye tamamen farklı bir perspektiften yaklaşan bir paradigmadır. Temelinde, programları bir dizi matematiksel fonksiyonun değerlendirilmesi olarak görür ve durumu değiştiren yan etkilerden (side effects) kaçınmayı hedefler. Bu, geleneksel imperatif programlamanın aksine, bir programın durumunu sürekli olarak değiştiren değişkenlere ve nesnelere odaklanmak yerine, girişleri alan ve çıktıları üreten saf fonksiyonlar yazmaya öncelik verir. Peki, bu yaklaşım ne gibi faydalar sağlar ve neden DDD ile birleştiğinde güçlü bir sinerji oluşturur?

FP’nin en temel prensibi Saf Fonksiyonlar (Pure Functions) kavramıdır. Saf bir fonksiyon, aynı girdilerle her zaman aynı çıktıyı üreten ve dış dünya ile hiçbir yan etkisi olmayan fonksiyondur. Yani, bir veritabanına yazmak, bir dosyaya kaydetmek veya global bir değişkeni değiştirmek gibi eylemler bir saf fonksiyon içinde yer almaz. Bu durum, fonksiyonları son derece öngörülebilir ve test edilebilir kılar. Düşünsenize, bir fonksiyonu test etmek için sadece girdilerini verip çıktısını kontrol etmeniz yeterlidir, çünkü başka hiçbir şeyi değiştirmeyeceğinden veya dışarıdan etkilenmeyeceğinden emin olabilirsiniz. Bu, birim testlerinin yazılmasını son derece kolaylaştırır ve hata ayıklama süreçlerini basitleştirir.

Diğer önemli bir FP ilkesi ise Değişmezlik (Immutability)‘tir. Fonksiyonel programlamada, veriler oluşturulduktan sonra asla değiştirilmez. Bunun yerine, bir veri yapısını değiştirmek istediğimizde, orijinal veriyi alıp, istenen değişiklikleri uygulayarak yeni bir veri yapısı oluştururuz. Bu yaklaşım, eşzamanlı (concurrent) programlamada ortaya çıkan birçok hatayı engeller, çünkü birden fazla iş parçacığı aynı anda aynı veriyi değiştirmeye çalışırken oluşan yarış koşulları (race conditions) ortadan kalkar. Her iş parçacığı kendi immutable veri kopyasıyla çalışır. Bu, özellikle modern çok çekirdekli işlemcilerde ve dağıtık sistemlerde performans ve güvenilirlik açısından büyük avantajlar sunar.

Yüksek Mertebeden Fonksiyonlar (Higher-Order Functions) ve Birinci Sınıf Fonksiyonlar (First-Class Functions) da FP’nin güçlü yönlerindendir. Birinci sınıf fonksiyonlar, fonksiyonların diğer veriler gibi değişkenlere atanabilmesini, argüman olarak başka fonksiyonlara geçirilebilmesini veya başka fonksiyonlardan döndürülebilmesini sağlar. Yüksek mertebeden fonksiyonlar ise, diğer fonksiyonları argüman olarak alan veya fonksiyon döndüren fonksiyonlardır. Bu yetenekler, soyutlamayı ve kodun yeniden kullanılabilirliğini artırır, daha kısa, daha okunabilir ve daha esnek kod yazmamıza olanak tanır. Örneğin, bir liste üzerindeki her öğeye bir işlem uygulamak için map veya filter gibi yüksek mertebeden fonksiyonlar kullanmak, imperatif döngüler yazmaktan çok daha temiz ve ifade edicidir. Tüm bu prensipler, yazılımın karmaşıklığını azaltmaya, hataları önlemeye ve sistemin genel olarak daha sağlam olmasına katkıda bulunur. Bu da, DDD’nin iş alanı karmaşıklığını yönetme hedefleriyle mükemmel bir uyum içindedir.

Fonksiyonel Yaklaşım DDD ile Nasıl Birleşir? İş Alanı Modellemeyi Yeniden Düşünmek

DDD, iş alanının karmaşıklığını yönetmeye odaklanırken, FP ise bu karmaşıklığı soyutlamaya ve yan etkileri minimize etmeye yardımcı olur. Bu iki güçlü paradigmayı birleştirmek, iş kurallarının daha net, daha öngörülebilir ve daha sürdürülebilir bir şekilde ifade edildiği sistemler tasarlamanın kapısını aralar. Peki, bu birleşimi somut olarak nasıl gerçekleştirebiliriz?

Değişmez Varlıklar ve Değer Nesneleri: Saf Modeller Yaratmak

Fonksiyonel DDD’nin temel taşlarından biri, tüm domain objelerini (Varlıklar ve Değer Nesneleri dahil) değişmez (immutable) hale getirmektir. Değişmezlik, bir nesne oluşturulduktan sonra durumunun asla değişmemesi anlamına gelir. Bir nesnede değişiklik yapılması gerektiğinde, orijinal nesnenin kopyası alınır ve yeni durumla yeni bir nesne oluşturulur. Bu yaklaşım, özellikle DDD’nin “tutarlılık” ilkesiyle mükemmel bir uyum içindedir, çünkü bir nesnenin durumu her zaman belirli bir anı temsil eder ve beklenmedik mutasyonlardan kaynaklanan hatalar ortadan kalkar.

Bir değer nesnesi (örneğin, bir para birimi veya bir adres) doğası gereği değişmez olmalıdır ve bu FP felsefesine doğrudan uyar. Ancak varlıklar (örneğin, bir Sipariş veya bir Müşteri) yaşam döngüsü boyunca durum değiştiren nesnelerdir. Fonksiyonel bir yaklaşımla, bir varlığın durumunu doğrudan değiştirmek yerine, bir “değişim fonksiyonu” tanımlarız. Bu fonksiyon, mevcut varlık durumunu ve ilgili olayı alarak, yeni bir varlık durumu döndürür. Bu, her bir durum değişikliğinin açıkça tanımlanmasını ve test edilmesini sağlar.

Örnek olarak, bir Kargo (Shipment) varlığını düşünelim. Durumu Beklemede, Kargoda, Teslim Edildi olabilir. Geleneksel OOP’de bir kargoyuGüncelle(yeniDurum) metodu yazabiliriz. Fonksiyonel yaklaşımda ise:

interface Kargo {
    id: string;
    takipNo: string;
    durum: "Beklemede" | "Kargoda" | "Teslim Edildi";
    gonderimTarihi: Date;
    teslimTarihi?: Date;
}

// Yeni bir durum ile Kargo nesnesinin yeni bir kopyasını döndüren saf fonksiyon
function kargoyuGuncelle(kargo: Kargo, yeniDurum: Kargo["durum"]): Kargo {
    // İş kuralları burada kontrol edilebilir
    if (kargo.durum === "Teslim Edildi" && yeniDurum !== "Teslim Edildi") {
        throw new Error("Teslim edilmiş kargo durumu değiştirilemez.");
    }

    const guncelTarih = new Date();
    const yeniKargo: Kargo = {
        ...kargo,
        durum: yeniDurum,
        teslimTarihi: yeniDurum === "Teslim Edildi" ? guncelTarih : kargo.teslimTarihi
    };

    return yeniKargo;
}

// Kullanım örneği
const baslangicKargo: Kargo = {
    id: "KRG123",
    takipNo: "TN456789",
    durum: "Beklemede",
    gonderimTarihi: new Date("2023-10-26")
};

const kargodakiKargo = kargoyuGuncelle(baslangicKargo, "Kargoda");
console.log(kargodakiKargo.durum); // Kargoda

const teslimEdilenKargo = kargoyuGuncelle(kargodakiKargo, "Teslim Edildi");
console.log(teslimEdilenKargo.durum); // Teslim Edildi
console.log(teslimEdilenKargo.teslimTarihi); // Bugünün tarihi
    

Yukarıdaki örnekte kargoyuGuncelle fonksiyonu, mevcut kargo nesnesini ve yeni durumu alarak tamamen yeni bir kargo nesnesi döndürür. Orijinal baslangicKargo nesnesi asla değişmez. Bu, referans şeffaflığı ve öngörülebilirlik sağlar.

Yan Etkisiz Domain Servisleri: İş Kurallarını Fonksiyonel Şekilde İfade Etmek

DDD'de Domain Servisleri, bir Varlık veya Değer Nesnesi içinde doğal olarak bulunmayan, ancak birden fazla domain objesini veya dış servisi içeren iş mantığını kapsülleyen yapılardır. Fonksiyonel bir yaklaşımla, bu servisleri saf fonksiyonlar olarak tasarlarız. Bu fonksiyonlar, sadece girdi parametrelerine bağlı olarak çıktı üretir ve hiçbir yan etkisi (veritabanı yazma, API çağrısı vb.) olmaz. Yan etkiler, uygulamanın en dış katmanlarına (application services, infrastructure) itilir.

Örneğin, bir e-ticaret sisteminde "Sipariş Tamamlama" işlemi bir domain servisi olabilir. Bu işlem, siparişin durumunu güncelleyebilir, stokları düşürebilir ve bir ödeme işleyiciye bilgi gönderebilir. Fonksiyonel bir DDD'de, bu işlemi bir dizi saf fonksiyon olarak modelleyebiliriz:

interface Siparis {
    id: string;
    musteriId: string;
    durum: "Oluşturuldu" | "Onaylandı" | "Tamamlandı" | "İptal Edildi";
    toplamTutar: number;
    urunler: { urunId: string; miktar: number }[];
}

interface Stok {
    urunId: string;
    mevcutMiktar: number;
}

// Siparişin durumunu güncelleyen saf fonksiyon
const siparisDurumunuGuncelle = (siparis: Siparis, yeniDurum: Siparis["durum"]): Siparis => ({
    ...siparis,
    durum: yeniDurum
});

// Stok miktarını düşüren saf fonksiyon
const stoguDusur = (stok: Stok, miktar: number): Stok => {
    if (stok.mevcutMiktar < miktar) {
        throw new Error(Yetersiz stok: ${stok.urunId});
    }
    return { ...stok, mevcutMiktar: stok.mevcutMiktar - miktar };
};

// Domain Servisi: Sipariş tamamlama iş akışını yöneten bir fonksiyon.
// Yan etkileri (veritabanı, ödeme) dışarıya delege eder.
const siparisiTamamla = (
    siparis: Siparis,
    mevcutStoklar: Stok[]
): {
    guncelSiparis: Siparis;
    guncelStoklar: Stok[];
    odemeIslemiGerekiyor: boolean;
} => {
    // İş kuralları ve durum geçiş kontrolleri
    if (siparis.durum !== "Onaylandı") {
        throw new Error("Sipariş sadece 'Onaylandı' durumundan tamamlanabilir.");
    }

    let guncelStoklar = [...mevcutStoklar];
    for (const urun of siparis.urunler) {
        const stokIndex = guncelStoklar.findIndex(s => s.urunId === urun.urunId);
        if (stokIndex === -1) {
            throw new Error(Ürün stokta bulunamadı: ${urun.urunId});
        }
        guncelStoklar[stokIndex] = stoguDusur(guncelStoklar[stokIndex], urun.miktar);
    }

    const guncelSiparis = siparisDurumunuGuncelle(siparis, "Tamamlandı");

    return {
        guncelSiparis,
        guncelStoklar,
        odemeIslemiGerekiyor: true // Ya da siparişin ödeme durumuna göre değişebilir
    };
};

// Kullanım örneği (uygulama katmanında)
const ornekSiparis: Siparis = {
    id: "Siparis001",
    musteriId: "Musteri001",
    durum: "Onaylandı",
    toplamTutar: 150.00,
    urunler: [{ urunId: "UrunA", miktar: 2 }, { urunId: "UrunB", miktar: 1 }]
};

const ornekStoklar: Stok[] = [
    { urunId: "UrunA", mevcutMiktar: 10 },
    { urunId: "UrunB", mevcutMiktar: 5 }
];

try {
    const { guncelSiparis, guncelStoklar, odemeIslemiGerekiyor } = siparisiTamamla(ornekSiparis, ornekStoklar);
    console.log("Güncel Sipariş Durumu:", guncelSiparis.durum); // Tamamlandı
    console.log("Güncel Stoklar:", guncelStoklar); // UrunA: 8, UrunB: 4

    // Bu noktada, dış servislere (veritabanı, ödeme geçidi) güncelleme çağrıları yapılır
    // Veritabanına guncelSiparis ve guncelStoklar kaydedilir.
    // Ödeme işlemi tetiklenir.
    if (odemeIslemiGerekiyor) {
        console.log("Ödeme işlemi tetiklendi.");
    }

} catch (error: any) {
    console.error("Sipariş tamamlama hatası:", error.message);
}
    

Burada siparisiTamamla fonksiyonu, mevcut sipariş ve stok bilgilerini alır, gerekli domain mantığını uygular ve güncellenmiş sipariş ve stok durumlarını döndürür. Veritabanına kaydetme veya ödeme işlemini gerçekleştirme gibi yan etkiler, bu fonksiyonun sorumluluğunda değildir; bunlar, fonksiyonun çıktısı alındıktan sonra uygulama servisleri katmanında ele alınır. Bu ayrım, iş mantığını son derece temiz ve test edilebilir kılar.

Aggregate Kökleri ve Durum Yönetimi: Kontrollü Değişim Nasıl Sağlanır?

Aggregate Kökleri, DDD'deki tutarlılık sınırlarını tanımlayan kritik yapılardır. Fonksiyonel DDD'de, bir Aggregate Kökünü de değişmez bir veri yapısı olarak tasarlarız. Bir Aggregate'deki herhangi bir değişikliği tetiklemek için, kök üzerindeki bir metot (veya dışarıdan bir fonksiyon) çağrılır. Bu metot, mevcut Aggregate durumunu ve bir veya daha fazla domain olayını (Domain Event) girdi olarak alır ve yeni bir Aggregate durumu ile bu olayı/olayları çıktı olarak döndürür. Bu model, özellikle Olay Kaynaklama (Event Sourcing) yaklaşımlarıyla mükemmel bir uyum içindedir.

Her bir Aggregate Kökü, içindeki tüm varlıkların ve değer nesnelerinin tutarlılığından sorumludur. Fonksiyonel bir Aggregate, durumu doğrudan değiştirmez; bunun yerine, durumu temsil eden yeni bir Aggregate nesnesi üretir ve meydana gelen domain olaylarını (eğer varsa) dışarıya bildirir. Bu olaylar daha sonra kalıcılığa kaydedilir ve diğer Sınırlı Bağlamlar tarafından tüketilebilir.

// Aggregate Kökü: Siparis
interface SiparisAggregate {
    id: string;
    musteriId: string;
    durum: "Beklemede" | "Onaylandı" | "Sevk Edildi" | "Teslim Edildi" | "İptal Edildi";
    urunler: { urunId: string; miktar: number; birimFiyat: number }[];
    toplamTutar: number;
    olusturmaTarihi: Date;
    guncellemeTarihi: Date;
}

// Domain Olayı: Sipariş Oluşturuldu
interface SiparisOlusturulduEvent {
    tip: "SiparisOlusturuldu";
    siparisId: string;
    musteriId: string;
    urunler: { urunId: string; miktar: number; birimFiyat: number }[];
    toplamTutar: number;
    tarih: Date;
}

// Domain Olayı: Sipariş Onaylandı
interface SiparisOnaylandiEvent {
    tip: "SiparisOnaylandi";
    siparisId: string;
    tarih: Date;
}

// Domain Olayı: Sipariş İptal Edildi
interface SiparisIptalEdildiEvent {
    tip: "SiparisIptalEdildi";
    siparisId: string;
    neden: string;
    tarih: Date;
}

type DomainEvent = SiparisOlusturulduEvent | SiparisOnaylandiEvent | SiparisIptalEdildiEvent;

// Yardımcı fonksiyon: Toplam tutarı hesapla
const hesaplaToplamTutar = (urunler: { miktar: number; birimFiyat: number }[]): number =>
    urunler.reduce((acc, item) => acc + (item.miktar * item.birimFiyat), 0);

// Fonksiyonel Aggregate Kökü İşlemleri
// Sipariş oluşturan saf fonksiyon
function siparisOlustur(
    siparisId: string,
    musteriId: string,
    urunler: { urunId: string; miktar: number; birimFiyat: number }[]
): { aggregate: SiparisAggregate; event: SiparisOlusturulduEvent } {
    const simdi = new Date();
    const toplamTutar = hesaplaToplamTutar(urunler);

    const yeniSiparis: SiparisAggregate = {
        id: siparisId,
        musteriId: musteriId,
        durum: "Beklemede",
        urunler: urunler,
        toplamTutar: toplamTutar,
        olusturmaTarihi: simdi,
        guncellemeTarihi: simdi
    };

    const olusturulduEvent: SiparisOlusturulduEvent = {
        tip: "SiparisOlusturuldu",
        siparisId: siparisId,
        musteriId: musteriId,
        urunler: urunler,
        toplamTutar: toplamTutar,
        tarih: simdi
    };

    return { aggregate: yeniSiparis, event: olusturulduEvent };
}

// Siparişi onaylayan saf fonksiyon
function siparisiOnayla(
    siparis: SiparisAggregate
): { aggregate: SiparisAggregate; event: SiparisOnaylandiEvent } {
    if (siparis.durum !== "Beklemede") {
        throw new Error("Sipariş sadece 'Beklemede' durumundayken onaylanabilir.");
    }
    const simdi = new Date();
    const guncelSiparis: SiparisAggregate = {
        ...siparis,
        durum: "Onaylandı",
        guncellemeTarihi: simdi
    };
    const onaylandiEvent: SiparisOnaylandiEvent = {
        tip: "SiparisOnaylandi",
        siparisId: siparis.id,
        tarih: simdi
    };
    return { aggregate: guncelSiparis, event: onaylandiEvent };
}

// Siparişi iptal eden saf fonksiyon
function siparisiIptalEt(
    siparis: SiparisAggregate,
    neden: string
): { aggregate: SiparisAggregate; event: SiparisIptalEdildiEvent } {
    if (siparis.durum === "Teslim Edildi") {
        throw new Error("Teslim edilmiş sipariş iptal edilemez.");
    }
    const simdi = new Date();
    const guncelSiparis: SiparisAggregate = {
        ...siparis,
        durum: "İptal Edildi",
        guncellemeTarihi: simdi
    };
    const iptalEdildiEvent: SiparisIptalEdildiEvent = {
        tip: "SiparisIptalEdildi",
        siparisId: siparis.id,
        neden: neden,
        tarih: simdi
    };
    return { aggregate: guncelSiparis, event: iptalEdildiEvent };
}

// Kullanım örneği (uygulama katmanında)
const { aggregate: yeniSiparis, event: olusturulduEvent } = siparisOlustur(
    "Siparis002",
    "Musteri002",
    [{ urunId: "UrunC", miktar: 1, birimFiyat: 75.00 }]
);
console.log("Yeni Sipariş Durumu:", yeniSiparis.durum); // Beklemede
console.log("Oluşan Olay:", olusturulduEvent);

const { aggregate: onayliSiparis, event: onaylandiEvent } = siparisiOnayla(yeniSiparis);
console.log("Onaylı Sipariş Durumu:", onayliSiparis.durum); // Onaylandı
console.log("Oluşan Olay:", onaylandiEvent);

try {
    const { aggregate: iptalEdilenSiparis, event: iptalEdildiEvent } = siparisiIptalEt(onayliSiparis, "Müşteri vazgeçti");
    console.log("İptal Edilen Sipariş Durumu:", iptalEdilenSiparis.durum); // İptal Edildi
    console.log("Oluşan Olay:", iptalEdildiEvent);
} catch (error: any) {
    console.error(error.message);
}
    

Bu yaklaşım, her bir işlemde hem Aggregate'in yeni durumunu hem de bu değişikliği açıklayan bir Domain Olayını açıkça döndürmemizi sağlar. Bu olaylar daha sonra veritabanına kaydedilerek (Event Sourcing), sistemin geçmiş durumunu tam olarak yeniden inşa etmemize olanak tanır ve diğer servislerle entegrasyonu kolaylaştırır.

Gerçek Dünya Senaryolarında Fonksiyonel DDD Uygulamaları: Bir E-Ticaret Örneği

Fonksiyonel DDD'nin gücünü daha iyi anlamak için, bir e-ticaret platformundaki karmaşık "Sipariş İşleme" süreçlerini ele alalım. Bu süreç, müşteri sipariş vermesinden, ödeme, stok yönetimi, kargolama ve nihayetinde teslimata kadar birçok farklı domain bağlamını ve iş kuralını içerir. Geleneksel OOP'de bu süreçler genellikle iç içe geçmiş sınıflar ve durum mutasyonlarıyla yönetilir, bu da test edilebilirliği ve bakımı zorlaştırabilir. Fonksiyonel bir yaklaşımla, her adımı öngörülebilir, bağımsız fonksiyonlar olarak modelleyebiliriz.

E-ticaret sistemimizde temel Sınırlı Bağlamlar şunlar olabilir:

• Sipariş Yönetimi (Order Management): Siparişin yaşam döngüsünü (oluşturma, onaylama, iptal etme) yönetir.
• Stok Yönetimi (Inventory Management): Ürün stoklarını takip eder ve günceller.
• Ödeme İşleme (Payment Processing): Müşteri ödemelerini alır ve işler.
• Kargo ve Lojistik (Shipping & Logistics): Siparişlerin paketlenmesini ve müşteriye teslimatını koordine eder.

Her bir bağlamı kendi içinde bağımsız fonksiyonlar ve değişmez veri yapıları ile modelleyebiliriz. Örneğin, "Sipariş Yönetimi" bağlamında, bir siparişin durum geçişleri saf fonksiyonlar olarak tanımlanır. Bir siparişin durumu "Beklemede" iken "Onaylandı" durumuna geçmesi, mevcut sipariş nesnesini girdi olarak alan ve yeni durumuyla yeni bir sipariş nesnesi döndüren bir fonksiyon aracılığıyla gerçekleşir. Bu fonksiyon aynı zamanda bir SiparisOnaylandi domain olayı da üretebilir.

Bu olaylar daha sonra diğer bağlamlar tarafından tüketilir. Örneğin, SiparisOnaylandi olayı "Stok Yönetimi" bağlamına iletilir. "Stok Yönetimi" bağlamındaki bir "Olay İşleyici" (Event Handler) bu olayı dinler, ilgili ürünlerin stoklarını düşürmek için kendi saf fonksiyonlarını kullanır ve muhtemelen StokAzaltildi veya StokYetersiz gibi yeni olaylar yayar. Aynı şekilde, "Ödeme İşleme" bağlamı da SiparisOlusturuldu olayını dinleyerek ödeme işlemini başlatır ve OdemeBasarili veya OdemeBasarisiz olayları üretir.

// Örnek: Sipariş oluşturma ve olay yayma
// Bu genellikle bir "Application Service" içinde orkestre edilir.
function siparisOlusturmaAkisi(
    musteriId: string,
    sepetUrunleri: { urunId: string; miktar: number; birimFiyat: number }[]
): { nihaiSiparis: SiparisAggregate; yayilanOlaylar: DomainEvent[] } {
    const siparisId = "generated-uuid"; // Gerçek uygulamada UUID üretimi
    const { aggregate: yeniSiparis, event: olusturulduEvent } = siparisOlustur(
        siparisId,
        musteriId,
        sepetUrunleri
    );

    // Uygulama katmanında, olayı kaydet ve yayınla
    // this.eventStore.save(olusturulduEvent);
    // this.eventBus.publish(olusturulduEvent);

    return { nihaiSiparis: yeniSiparis, yayilanOlaylar: [olusturulduEvent] };
}

// Örnek: Bir olay dinleyici (Stok Yönetimi Bağlamında)
// Bu bir Olay İşleyici (Event Handler) fonksiyonu olabilir.
function stokAzaltmaIsleyici(
    olay: SiparisOlusturulduEvent,
    mevcutStoklar: Stok[]
): { guncelStoklar: Stok[]; yeniOlaylar: DomainEvent[] } {
    if (olay.tip !== "SiparisOlusturuldu") {
        return { guncelStoklar: mevcutStoklar, yeniOlaylar: [] };
    }

    let guncelStoklar = [...mevcutStoklar];
    let yeniOlaylar: DomainEvent[] = [];

    for (const urun of olay.urunler) {
        const stokIndex = guncelStoklar.findIndex(s => s.urunId === urun.urunId);
        if (stokIndex === -1 || guncelStoklar[stokIndex].mevcutMiktar < urun.miktar) {
            yeniOlaylar.push({
                tip: "StokYetersiz",
                siparisId: olay.siparisId,
                urunId: urun.urunId,
                talepEdilenMiktar: urun.miktar,
                mevcutMiktar: stokIndex !== -1 ? guncelStoklar[stokIndex].mevcutMiktar : 0,
                tarih: new Date()
            });
            // Burada sipariş iptali veya bekleme durumuna alma gibi mantık yürütülebilir.
            continue;
        }
        guncelStoklar[stokIndex] = stoguDusur(guncelStoklar[stokIndex], urun.miktar);
        yeniOlaylar.push({
            tip: "StokAzaltildi",
            siparisId: olay.siparisId,
            urunId: urun.urunId,
            azaltilanMiktar: urun.miktar,
            kalanMiktar: guncelStoklar[stokIndex].mevcutMiktar,
            tarih: new Date()
        });
    }

    return { guncelStoklar, yeniOlaylar };
}
    

Bu akışta, her bir adım bir dizi saf fonksiyon olarak modellenir ve domain olayları, farklı bağlamlar arasında iletişimi sağlayan değişmez mesajlar olarak görev yapar. Bu, sistemi son derece modüler, test edilebilir ve her bir parçanın ayrı ayrı geliştirilebilmesini mümkün kılar. Aynı zamanda, olay günlüğü (event log) sayesinde sistemin herhangi bir zamandaki durumunu yeniden oluşturmak mümkün hale gelir, bu da hata ayıklama ve denetim süreçlerini büyük ölçüde kolaylaştırır.

Bu makale, mobil cihazlarda da rahatlıkla okunabilmesi için optimize edilmiştir. CSS media query örnekleri ile responsive tasarımın nasıl sağlanabileceğini aşağıda görebilirsiniz.

/* Genel stil tanımlamaları */
body {
    font-family: Arial, sans-serif;
    line-height: 1.6;
    margin: 0 auto;
    max-width: 960px;
    padding: 20px;
}

h2 {
    color: #2c3e50;
    margin-top: 30px;
}

p {
    margin-bottom: 15px;
}

pre {
    background-color: #f4f4f4;
    padding: 15px;
    border-radius: 5px;
    overflow-x: auto; /* Yatay kaydırma çubuğu */
}

/* Mobil cihazlar için özelleştirmeler (örneğin 600px genişlikten küçük ekranlar) */
@media screen and (max-width: 600px) {
    body {
        padding: 10px;
    }
    h2 {
        font-size: 1.5em;
    }
    p, pre {
        font-size: 0.9em;
    }
}

/* Tabletler için özelleştirmeler (örneğin 601px - 900px arası) */
@media screen and (min-width: 601px) and (max-width: 900px) {
    body {
        padding: 15px;
    }
    h2 {
        font-size: 1.8em;
    }
}
    

Fonksiyonel DDD'nin Avantajları ve Karşılaşılabilecek Zorluklar Nelerdir?

Her güçlü metodoloji gibi, Fonksiyonel DDD'nin de kendine özgü avantajları ve potansiyel zorlukları bulunmaktadır. Bu yaklaşıma geçiş yapmayı düşünen ekiplerin bu noktaları dikkatlice değerlendirmesi önemlidir.

Avantajlar: Neden Denemelisiniz?

Fonksiyonel Programlama prensiplerinin DDD ile birleşimi, yazılım geliştirme sürecine birçok kritik fayda sağlar:

• Daha Yüksek Test Edilebilirlik: Saf fonksiyonlar ve değişmez veri yapıları sayesinde, birim testleri yazmak son derece kolaylaşır. Her fonksiyon, dış dünyadan bağımsız olduğu için, sadece girdileriyle test edilebilir. Bu, daha az sahte nesneye (mock) ihtiyaç duyulması ve daha güvenilir test paketleri anlamına gelir.
• Gelişmiş Modülerlik ve Kapsülleme: Fonksiyonel yaklaşım, iş mantığını küçük, bağımsız ve odaklanmış fonksiyonlara bölmeyi teşvik eder. Bu, her bir domain kavramının kendi sorumluluğunu daha net bir şekilde yerine getirmesini sağlar ve kodun daha modüler olmasını teşvik eder.
• Artırılmış Öngörülebilirlik ve Hata Toleransı: Yan etkilerin en aza indirilmesi ve değişmezlik, kodun davranışını tahmin etmeyi çok daha kolay hale getirir. Belirli bir girdiyle bir fonksiyonun her zaman aynı çıktıyı üreteceği garantisi, beklenmedik hataları ve hata ayıklama süresini önemli ölçüde azaltır. Çoklu iş parçacıklı (multithreaded) ortamlarda bile durum çakışmaları (race conditions) endişesi ortadan kalkar.
• Kolay Paralelleştirme ve Ölçeklenebilirlik: Değişmez veriler ve yan etkisiz fonksiyonlar, kodun paralel ortamlarda daha güvenli bir şekilde çalıştırılmasını sağlar. Bu, modern çok çekirdekli işlemcilerden tam anlamıyla faydalanabilen ve dağıtık sistemlerde daha iyi ölçeklenebilirlik sunan uygulamalar geliştirmek için ideal bir temel oluşturur.
• Daha Net Domain Modelleri: FP, iş kurallarını veri dönüşümleri olarak ifade etmeyi teşvik eder. Bu, domain modelinin işleyişini daha açık ve şeffaf hale getirir. Domain olaylarının kullanımıyla birleştiğinde, sistemin durumu ve geçirdiği tüm değişiklikler açıkça izlenebilir olur.
• Gelişmiş Denetlenebilirlik ve Hata Ayıklama: Olay kaynaklama (event sourcing) ile birleştiğinde, her bir domain olayının kaydı, sistemin geçmişteki herhangi bir anındaki durumunu yeniden oluşturmayı mümkün kılar. Bu, hata ayıklama, denetim ve iş analizi için muazzam bir değer sunar.

Karşılaşılabilecek Zorluklar: Nelere Dikkat Etmeli?

Fonksiyonel DDD'nin cazip faydalarına rağmen, bu yaklaşıma geçerken bazı zorluklarla karşılaşmak da mümkündür:

• Öğrenme Eğrisi: Geleneksel nesne yönelimli programlamadan (OOP) gelen geliştiriciler için fonksiyonel programlama prensipleri (saf fonksiyonlar, değişmezlik, yüksek mertebeden fonksiyonlar) başlangıçta soyut ve zorlayıcı gelebilir. Yeni düşünce biçimleri ve tasarım kalıpları öğrenmek zaman ve çaba gerektirir.
• Mevcut Araç ve Kütüphane Ekosistemi: Her ne kadar FP dilleri ve kütüphaneleri hızla gelişiyor olsa da, özellikle kurumsal yazılım alanında OOP tabanlı çerçeveler ve araçlar hala çok daha yaygındır. Fonksiyonel DDD'yi benimserken, bazı araçların veya kütüphanelerin FP prensipleriyle doğrudan uyumlu olmaması gibi zorluklarla karşılaşılabilir. Ancak, birçok modern dil (JavaScript, Python, C#) artık FP özelliklerini güçlü bir şekilde desteklemektedir.
• Performans Kaygıları (Yanlış Anlama): Değişmez veri yapılarının her değişimde yeni bir nesne oluşturması, bazı geliştiricilerde performans endişelerine yol açabilir. Ancak modern FP dilleri ve kütüphaneleri, bu kopyalama işlemlerini optimize etmek için yapısal paylaşım (structural sharing) gibi akıllı teknikler kullanır. Çoğu durumda, bunun performansa etkisi ihmal edilebilir düzeydedir ve elde edilen mimari avantajlar bu küçük potansiyel maliyeti fazlasıyla aşar. Kritik performans noktalarında ise, mutasyona izin veren küçük ve izole edilmiş kod blokları kullanılabilir, ancak bunlar dikkatle yönetilmelidir.
• Alışkanlıkları Değiştirmek: Yıllardır OOP ile çalışmış bir ekip için, durum mutasyonundan ve nesne odaklı düşünceden uzaklaşmak, alışkanlıkları değiştirmeyi gerektirir. Bu, eğitim, mentörlük ve pratik deneyimle aşılabilir bir zorluktur.
• Debugging Karmaşıklığı: Saf fonksiyonlar hata ayıklamayı kolaylaştırsa da, özellikle monadlar veya fonksiyonel borulama (pipelining) gibi ileri seviye FP kavramları kullanıldığında, karmaşık fonksiyon zincirlerinin hata ayıklaması başlangıçta zorlayıcı olabilir. Ancak, bu durum genellikle daha az hataya yol açtığı için genel hata ayıklama süresi azalır.

Sonuç

Domain-Driven Design ve Fonksiyonel Programlama arasındaki evlilik, modern yazılım geliştirme pratikleri için oldukça güçlü ve umut vadeden bir sentez sunmaktadır. DDD'nin iş alanına derinlemesine odaklanması ve karmaşık iş mantığını anlamlandırma yeteneği, Fonksiyonel Programlama'nın saflık, değişmezlik ve yan etkisiz kod prensipleriyle birleştiğinde, hem işin gereksinimlerini doğru bir şekilde karşılayan hem de yüksek kaliteli, bakımı kolay ve ölçeklenebilir sistemler inşa etmenin yolunu açar. Bu yaklaşım, yazılımın karmaşıklığını yönetmek, hataları azaltmak ve ekiplerin daha verimli çalışmasını sağlamak için sağlam bir temel sunar.

Elbette, bu paradigmaların birleşimi bir öğrenme eğrisi ve mevcut alışkanlıkların değişimi gerektirir. Ancak, elde edilecek avantajlar – daha öngörülebilir kod tabanları, üstün test edilebilirlik, kolay paralel işleme ve daha net domain modelleri – bu çabaya kesinlikle değer. Geliştiriciler, DDD'nin stratejik tasarım araçlarını (Sınırlı Bağlamlar, Ubiquitous Language) ve taktiksel kalıplarını (Varlıklar, Değer Nesneleri, Aggregate'ler) fonksiyonel prensiplerle birleştirerek, iş domain'inin kalbinden doğan, esnek ve geleceğe hazır sistemler yaratma potansiyeline sahiptir. Unutmayın, nihai hedef, teknoloji seçimi ne olursa olsun, işin ihtiyaçlarına en uygun ve sürdürülebilir çözümü sunmaktır.

Sıkça Sorulan Sorular (SSS)

Fonksiyonel DDD sadece belirli dillerde mi uygulanabilir?

Hayır, Fonksiyonel DDD prensipleri dilden bağımsızdır, ancak bazı diller (Haskell, Scala, Elixir gibi) fonksiyonel programlamayı doğal olarak daha iyi destekler. Ancak modern JavaScript (TypeScript ile), Python, C# (LINQ ve immutable koleksiyonlarla) gibi dillerde de bu prensipleri etkili bir şekilde uygulayabilirsiniz. Önemli olan, dilin sunduğu imkanları kullanarak saf fonksiyonlar ve değişmezlik gibi kavramları benimsemektir.

Neden doğrudan OOP tabanlı DDD yerine Fonksiyonel DDD tercih etmeliyim?

Fonksiyonel DDD, özellikle yan etkilerin ve durum mutasyonlarının kontrolünün zorlaştığı karmaşık domain'lerde daha fazla öngörülebilirlik, test edilebilirlik ve eşzamanlılık güvenliği sunar. Eğer sisteminizin yüksek güvenilirlik, ölçeklenebilirlik ve hata toleransı gereksinimleri varsa, FP prensipleriyle güçlendirilmiş DDD daha sağlam bir temel sağlayabilir.

Fonksiyonel DDD için hangi araçlar veya kütüphaneler önerilir?

Seçtiğiniz dile göre değişir. TypeScript/JavaScript için immer (immutable durum yönetimi için), fp-ts veya lodash/fp gibi kütüphaneler faydalı olabilir. Scala için Akka, ZIO veya Cats gibi kütüphaneler event-driven ve fonksiyonel mimarileri destekler. Önemli olan, dili ve ekosistemi derinlemesine öğrenmek ve FP prensiplerini destekleyen yapıları benimsemektir.

Aggregate Kökleri fonksiyonel bir yaklaşımla nasıl yönetilir?

Fonksiyonel bir Aggregate Kökü, durumu doğrudan değiştirmez. Bunun yerine, mevcut durumu girdi olarak alır, iş kurallarını uygular ve yeni durumu temsil eden yeni bir Aggregate nesnesi ile birlikte meydana gelen domain olaylarını (varsa) çıktı olarak döndürür. Bu olaylar daha sonra kalıcı hale getirilir ve diğer servisler tarafından işlenebilir. Bu desen, genellikle Olay Kaynaklama (Event Sourcing) ile birlikte kullanılır.

Fonksiyonel DDD'ye geçiş yaparken nelere dikkat etmeliyiz?

Geçiş sürecinde en önemli adımlar, ekibin fonksiyonel programlama prensiplerini öğrenmesi için yeterli eğitim ve zaman sağlamaktır. Küçük, izole edilmiş bir bounded context veya yeni bir özellik üzerinde fonksiyonel DDD uygulamaya başlamak, öğrenme sürecini kolaylaştırabilir. Ayrıca, tüm sistemi bir anda değiştirmek yerine, adım adım ve kademeli bir geçiş planı yapmak en sağlıklısı olacaktır. Kod incelemeleri ve mentorluk da bu süreçte kritik rol oynar.