Net Core'da Event-Driven Architecture ve Domain Driven Design

Merhaba,

Modern yazılım projeleri büyüdükçe, onların davranışlarını yönetmek ve karmaşik iş kurallarını (business rules) düzenli şekilde ele almak zorlaşır. Bu nedenle iki yaklaşım özellikle öne çıkar: Olay güdümlü mimari (Event-Driven Architecture) ve Alan odaklı tasarım (Domain-Driven Design – DDD). .NET Core ekosistemi, bu iki yaklaşımı uygulamak için oldukça uygun bir altyapı sunar. Bu yazıda her iki yaklaşımı da basit ve anlaşılır şekilde ele alacağım.

Event-Driven Architecture

Temel Mantık

Bu yaklaşım, sistem içindeki bileşenlerin olayları birbirine göndermesi ve diğer bileşenlerin bu olaylara tepki vermesi prensibine dayanır. Sistem doğrudan birbirine bağlı nesneler yerine, olaylar üzerinden iletişim kurar.

Gerçek Dünya Örneği

Bir e-ticaret sistemi düşünelim:

1. Kullanıcı bir ürün satın aldığında Sipariş Oluşturuldu olayı tetiklenir.
2. Bu olayı dinleyen başka bir servis fatura üretir.
3. Başka bir servis kargolama işlemini başlatır.
4. Bir başka servis stoktan düşme işlemi yapar.

Bu servisler birbirini doğrudan bilmez; sadece olaylara tepki verir. Böylece servislerin bağımlılığı azalır.

.NET Core’da Nasıl Uygulanır?

En popüler yöntemler:

1. Mesaj kuyrukları: RabbitMQ, Azure Service Bus, Kafka
2. Event Publisher / Subscriber (Yayıncı – Abone) yapısı

Avantajları

1. Gevşek Bağlılık: Servisler birbirini doğrudan tanımaz.
2. Yüksek Ölçeklenebilirlik: Yoğun veri yüklerinde kuyruk sistemi devreye girer.
3. Esnek Genişleme: Yeni bir servis olaya abone olduğunda sistemi bozmaz.
4. Gerçek Zamanlı Tepki: Olay üretildiği anda işlem tetiklenir.

Dezavantajları

1. Hata Takibi Zordur: Olayların nereden nereye aktığını anlamak karmaşık olabilir.
2. Gecikme Olabilir: Kuyruk yapıları küçük gecikmelere neden olabilir.
3. Tutarlılık (Consistency – Tutarlılık) Sorunları: Olaylar sıralı gelmeyebilir veya geç gelebilir.

Domain-Driven Design

Temel Mantık

Domain Driven Design, yazılımın iş alanına odaklanmasını sağlayan bir tasarım yaklaşımıdır. Amaç, modelleri iş kurallarını en doğru şekilde temsil edecek biçimde tasarlamaktır.

Gerçek Dünya Örneği

Bir banka sistemi düşünelim:

1. Hesap (Account – Hesap)
2. Para aktarımı (Transfer – Para aktarımı)
3. Limit kontrolü
4. İşlem geçmişi

Bu kavramların her biri iş alanına ait kavramlardır ve kod içinde doğrudan bu domain kavramlarıyla tanımlanır.
Örneğin:

public class BankaHesabi
{
    public decimal Bakiye { get; private set; }

    public void ParaYatir(decimal miktar)
    {
        if (miktar <= 0)
            throw new Exception("Yatırılacak miktar pozitif olmalıdır.");

        Bakiye += miktar;
    }
}

Burada iş kuralı (“miktar pozitif olmalı”) nesnenin kendi içinde yönetiliyor. Bu yaklaşım DDD'nin temelidir.

.NET Core'da DDD Katmanları

Genelde dört temel katman kullanılır:

1. Domain (Alan)

   • Entity (Varlık), Value Object (Değer Nesnesi), Domain Event (Alan Olayı)

2. Application (Uygulama)

   • İş akışlarını yöneten servisler

3. Infrastructure (Altyapı)

   • Veri tabanı, mesaj kuyrukları, dış servis bağlantıları

4. API (Sunum)

   • İstekleri karşılayan kontrolcüler

Bu yapı, özellikle kurumsal .NET Core projelerinde standart bir pratik haline gelmiştir.

Avantajları

1. Karmaşık İş Kurallarını Düzenler
2. Kod Gerçek İş Sürecine Benzer: Teknik ve iş ekipleri ortak dil kullanır.
3. Test Edilebilirlik Yüksektir
4. Uzun Ömürlü Projeler İçin Uygundur

Dezavantajları

1. Başlangıçta Karışık Görünebilir
2. Küçük Projeler İçin Fazla Ağır Olabilir
3. Doğru Uygulanmazsa “Aşırı Mimarileştirme” sorunu yaratır

Olay Güdümlü Mimari + DDD Birlikte Kullanılabilir mi?

Evet. genelde birçok büyük .NET Core projesi bu iki yaklaşımı birlikte kullanır.

Örnek mimari:

1. Domain içinde Alan Olayı (Domain Event) üretilir.

2. Bu olay Application katmanına yansır.

3. Application katmanı bu olayı dış dünyaya Olay Yayıncısı (Event Publisher) ile gönderir.

4. Başka servisler bu olaya abone olur.

Bu entegrasyon şu senaryolarda çok kullanışlıdır:

1. Mikroservis (Microservice – Mikroservis) mimarileri

2. Fatura, sipariş, stok yönetimi gibi bağımsız süreçler

3. Bankacılık ve sigorta gibi karmaşık domain’ler

Gerçek Dünya Senaryosu: E-Ticaret Ödeme Süreci

1. Sipariş Servisi, “Sipariş Oluşturuldu” olayını yayınlar.

2. Ödeme Servisi, bu olayı dinler ve ödeme işlemini başlatır.

3. Ödeme başarılı olunca domain içinde “Ödeme Başarılı” olayı tetiklenir.

4. Bu olay fatura servisine ve stok servisine iletilir.

5. Tüm servisler birbirinden bağımsız çalışır.

Bu yapı hem DDD hem Event-Driven prensiplerinin birleşimidir.

Sonuç

 bu iki yaklaşım:

1. Daha ölçeklenebilir,
2. Daha düzenli,
3. Daha sürdürülebilir,
4. Daha profesyonel

projeler geliştirmemizi sağlar.

Diğer Bloglarımda görüşmek üzere 👋