mfurkanayhan// çözüm atölyesi
← Yazılar

Mimari ·

“Bu kütüphaneyi asla ticarileştirmeyeceğim”

Bunu söyleyen kişi iki ay sonra fiyat listesini yayınladı.

MediatR’ın hikâyesi bu. Nisan 2025’te duyuru geldi, Temmuz 2025’te ticari sürüm çıktı. AutoMapper aynı yolu izledi, MassTransit de.

Kimse kötü niyetli davranmadı. Bogard gerekçesini açıkça yazdı: tek başına danışmanlık yaparken bu kütüphaneleri sürdürecek zamanı kalmamıştı. Anlaşılır bir karar.

Sorun kararda değil. Sorun, o sabah uyanıp kod tabanınıza baktığınızda ne göreceğinizde.

Solda sarmalanmamış proje: kütüphane tipleri 200’den fazla dosyaya dağılmış. Sağda Core katmanı üzerinden tek temas noktası.

Herkesin yaptığı şey

MediatR’ı kullanan bir projede IRequest, IRequestHandler, ISender tipleri her yere dağılır. Yüzlerce dosyada using satırı, yüzlerce sınıfta arayüz implementasyonu.

Bu normal. Kütüphane zaten bunun için var.

Ama şu soruyu kimse sormaz: bu kütüphane yarın gitse, kaç dosyaya dokunmam gerekir?

Cevabı geç öğrenmek

Lisans değişikliği duyurulduğunda seçenekleriniz şunlar:

Ücretsiz katmanda kalırsınız — ekip büyüdüğünde sınırı aşarsınız. Lisans alırsınız — bütçe kalemi açarsınız. Ya da geçiş yaparsınız.

Üçüncüsünün maliyeti, kütüphanenin kod tabanınıza ne kadar yayıldığıyla doğru orantılı. Ve bunu ölçmenin zamanı, duyuru günü değil.

9 projede denediğim şey

Backend’lerimde Core diye ayrı bir katman var. İçinde iş mantığı yok; sadece üçüncü parti kütüphanelerin sarmalayıcıları duruyor. MediatR, Mapster, FluentValidation, Scrutor.

Uygulama katmanı MediatR’ı doğrudan tanımıyor. Core’un tiplerini tanıyor.

Bu katman kurulduğunda fazladan iş gibi görünüyordu. Beş katman yerine dört yeterdi, bir dolaylılık eksik olurdu, yeni gelen geliştirici bir soru daha sormazdı.

Nisan 2025’te o fazladan katman, tek dosyada verilecek bir karara dönüştü.

Nereden başlanır

Bağımlılıklarınızı ikiye ayırın. Bir kısmı gitse projeyi yeniden yazarsınız — .NET, EF Core, Angular. Bunları sarmalamak anlamsız. Diğer kısmı yerine başkası konabilir — mapper, mediator, validator, logger. Asıl mesele bunlar.

İkinci grubu ölçün. grep -r "MediatR" --include="*.cs" | wc -l size bir sayı verir. O sayı, geçiş maliyetinizdir.

Sadece kullandığınız yüzeyi sarmalayın. Kütüphanenin tamamını taklit etmeyin; kendi ihtiyacınız kadarını.

Lisansı bağımlılık kriteri yapın. Yeni paket seçerken yıldız sayısına bakıldığı kadar lisans modeline ve kimin finanse ettiğine de bakın.

Karşılığında ne veriyorsunuz

Sarmalama bedava değil. Fazladan bir katman, fazladan dolaylılık, yeni geliştirici için fazladan öğrenme yükü. Yığındaki her kütüphaneyi sarmalarsanız kendi mini framework’ünüzü yazmış olursunuz — bu da ayrı bir sorun.

Denge şurada: değiştirilebilir olması gerekenleri sarmalayın, altyapının kendisini değil.

Özet

  • MediatR, AutoMapper ve MassTransit 2025’te ticari modele geçti.
  • Kimsenin kötü niyeti yoktu; sürdürülebilirlik meselesiydi.
  • Geçiş maliyetiniz, kütüphanenin kaç dosyaya yayıldığı kadardır.
  • O sayıyı duyuru günü değil, bugün ölçün.
  • Değiştirilebilir olanı sarmalayın; altyapıyı değil.

Kod tabanınızda hangi kütüphane en çok dosyaya dokunuyor? Bir grep bir sayı verir — o sayıyı görmek genelde rahatsız edicidir.