Domain Mantığı ve Boru Hatları ile CQRS İşleyicileri (C#) - Derek Comartin'in Videosu ile Açıklandı

Şişkin İşleyicilerle İlgili Sorunlar

Derek, birçok web uygulamasında yaygın bir senaryoyu vurgulayarak başlıyor: bir CQRS işleyicisini C#'ta açarsınız ve bir karmaşadır. Veri doğrulama, yetkilendirme, iş mantığı, durum geçişleri, olay yayınlama, günlükleme — hepsi iç içe geçmiş bir durumdadır.

Bunu bir sevkiyat gönderilmesine yönelik bir komut nesnesi kullanarak gösterir. İşleyici şunlardan sorumludur:

• Sevkıyatı yüklemek için veri deposuna erişmek.

• Sevkiyat durumunun hazır olup olmadığını kontrol etmek.

• Durumu güncellemek (yani, verileri güncellemek).

• Verileri geri veri erişim katmanına kaydetmek.

• Bir e-posta göndermek.

• Bir alan olayı yayınlamak.

Tüm bunlar tek bir yerde olur. Bu durum CQRS deseninin amacını ihlal eder, çünkü amaç endişeleri ayırmak ve performansı ve sürdürülebilirliği iyileştirmektir.

Alan Mantığını Veri Modeline Taşımak

Derek'in ilk adımı, doğrulama ve durum geçiş mantığını veri modeline taşımaktır. Sevkiyat sınıfı içinde bir Dispatch() yöntemi oluşturur. İşte bu, alan mantığının yer aldığı yerdir.

İşleyicide sevkiyat durumunu manuel olarak kontrol etmek yerine, bu mantık bu yöntemde kapsüllenir, böylece veri bütünlüğü ve her yerde sevkiyat tetiklendiğinde tutarlı bir davranış sağlanır. Bu, CQRS tabanlı uygulamanızda temiz mimariyi uygulamak için bir anahtardır.

Örneğin, sevkiyat.Dispatch() çağrısını yapan herhangi bir yer, otomatik olarak tüm doğrulamaları ve durum geçişlerini gerçekleştirir. Bu, işleyici ile alan mantığı arasında net bir ayrım sağlamak için CQRS tasarım deseni ile uyumludur.

Mantığı Merkezileştirmenin Değeri

Derek, bu tür bir değişikliğin gereksiz soyutlamalar eklemekle ilgili olmadığını belirtir. Bunun yerine, uygulama kodunuzun farklı bölümlerinde kullanılan mantığı merkezileştirmekle ilgilidir. Birden fazla komut işleyici bir sevkiyatı göndermesi gerekiyorsa, bu özel mantık bir yerde, yani alan modeli içinde bulunmalıdır.

Bu, veri modelinizi daha sağlam hale getirir ve CQRS işleyici C# uygulamalarınızı daha basit ve sürdürülebilir hale getirir.

Pipeline Paternini Tanıtmak

Komut işleyiciyi daha da temizlemek için Derek bir pipeline yani ardışık düzen şablonu tanıtıyor. Bu yapı, komutu küçük, tek amaçlı adımlar dizisi olarak işler ve her biri bir bağlam nesnesi alır ve bir sonraki adımı çağırır.

Bu, ASP.NET Core ara katmanı ile kavramsal olarak benzer, ve her adım akışın belirli bir parçasına odaklanır:

• Sevkiyatı alma (yani, veriyi okuma)

• Onu sevk etme (yazma işlemlerini yürütme)

• Olayları yayınlama

• Veriyi veri deposuna kaydetme

Bu adımlar, pipeline boyunca akan paylaşılan bir komut nesnesi kullanır. Bu, komut ve sorgu sorumluluğu ayrımının temiz ve modüler bir uygulamasını oluşturur.

Pipeline'ın Örnek Uygulaması

Örnek uygulamasında Derek, pipeline'ı şu adımlar gibi yapılandırıyor:

• Sevkiyatı yükleme - bir depo kullanarak veri erişimi katmanından veriyi çekme.

• Sevkiyatı sevk etme - alan mantığını uygulamak için Dispatch() yöntemini çağırma.

• Bir domain olayı ekleme - duruma "Sevkiyat Gönderildi" olayını ekleme.

• Olayları yayınlama - dış sistemlere bildirim göndermek için olayları yayma.

• Değişiklikleri kaydetme - veri deposuna güncellemeleri kaydetme.

Her adım, komut mantığının bağımsız bir parçasını temsil eder, veri doğruluğunu artırır ve sorumlulukları ayırır.

Derek ayrıca e-posta bildirimlerinin artık alan olayı yanıtlayarak ayrı bir şekilde ele alındığını belirtir. Bu, olay kaynaklı ilkelerle uyumlu ve nihai tutarlılığı teşvik eder.

Test ve Bakım Faydaları

Bu desenin en büyük avantajlarından biri test edilebilirliktir. Büyük bir komut işleyicisinde, birkaç bağımlılık olabilir (örneğin, depolar, posta hizmetleri, günlükleyiciler). Ancak işleyici pipeline adımlarına ayrıldığında, her biri sadece birkaç bağımlılık gerektirir.

Bu modüler yaklaşım, her bir adımı bağımlılık enjeksiyonu ile kolayca test etmenizi sağlar, gerektiğinde sahte veya taklitte kullanılır. Örneğin, Dispatch() çağıran bir adımı test ediyorsanız, bir e-posta hizmeti veya olay yayımcısını taklit etmenize gerek yoktur.

Bu endişe ayırımı, sorumluluk ayrımı CQRS kalıbını takip eder, okuma ve yazma modellerinizi daha temiz ve daha odaklanmış hale getirir.

Kompozitlik ve Yeniden Kullanılabilirlik

Pipeline yaklaşımının bir diğer faydası kompozit olmasıdır. Outbox Patteri gibi bir şey kullanıyorsanız, olayların yalnızca yazma modelleri kalıcı hale geldikten sonra yayımlanmasını sağlayabilirsiniz. Bu kontrol seviyesi, tutarlılık ve teslimat garantilerinin değerli olduğu CQRS uygulamalarında önemlidir.

Farklı CQRS işleyicileri arasında adımları da paylaşabilirsiniz — örneğin, genel bir "Değişiklikleri Kaydet" adımı veya "İstekleri Doğrula" adımı.

MediatR kütüphanesi gibi komut ve sorgu işleme destekleyen araçları kullanarak, bu adımları .NET Core uygulamanızda IServiceCollection hizmetleri aracılığıyla bağımlılık enjeksiyonu ile bile kaydedebilirsiniz.

Bu sistemi kurarken, Visual Studio'nun Paket Yöneticisi Konsol'u aracılığıyla Install-Package MediatR çalıştırmanız gerekebilir — C#'ta CQRS uygularken yaygın bir adım.

Değiş Tokuşlar

Derek, bu yaklaşımın getirdiği artan karmaşıklıktan kaçınmıyor. Pipelines dolaylılık tanıtır ve bir çağrı yığınına bakarken, bir labirentte geziniyor gibi hissedebilirsiniz.

Ancak, karmaşık iş mantığı için bu değiş tokuş çoğu zaman değerlidir. Bir işleyicide 10'dan fazla bağımlılık ve yüzlerce mantık satırı varsa, CQRS, geliştiricilerin bu akışları daha iyi yapılandırmasına ve bakımını sağlamasına olanak tanır.

Ne Zaman Refaktör Yapılmalı Konusundaki Son Düşünceler

Derek, izleyicilere CQRS işleyici C# uygulamalarının gerçekten şişkin olup olmadığını dikkatlice değerlendirmelerini hatırlatarak bitiriyor. Her senaryo bir pipeline gerektirmez. Onun amacı, olasılıkları illüstre etmektir ve geliştiricilerin kendi CQRS uygulamalarını değerlendirip bu tür desenlerin yardımcı olup olmayacağını belirlemeleridir.

Geliştiricilere, endişe alanlarının ayrılmasının tutarlılığı koruyacağı, kodu daha modüler yapacağı ve okuma ve yazma işlemlerini daha iyi yöneteceği alanlara bakmalarını teşvik ediyor — özellikle CQRS web uygulamalarında.

Sonuç

Derek Comartin'in videosu, domain mantık kapsama ve pipeline'lar kullanarak CQRS işleyicilerini temizlemek için pratik bir rehber sunuyor. Bu yaklaşım, kod şişkinliği sorunlarını ele almaya, veri bütünlüğünü teşvik etmeye ve uygulama kodunu belirgin modellere ayırarak sürdürülebilirliği arttırmaya yardımcı olur.

İster çalışan verilerini işleyin, ister ürün ayrıntılarını veya yeni bir kullanıcı komutu, CQRS kalıbını pipeline ve alana yönelimli tasarımla uygulayarak kod tabanınızı daha ölçeklenebilir, test edilebilir ve sağlam hale getirirsiniz.

Veri transfer nesneleri, ayrı modeller kullanarak ve okuma ve yazma mantığı arasında açık bir ayrım yaparak, .NET uygulamanız daha iyi yapılandırılır ve zaman içinde evrimleşmesi daha kolay hale gelir.