.Net Core Onion Architecture + CQRS + MediatR Full Video

[@AtalayKeskin]

Mükemmel yorumlamışsınız. Çok net açıklayıcı olmuş. Ağızınıza sağlık.

[@TechBuddyTR]

Çok teşekkür ederim. İyi seyirler

[@nazlcankurt1490]

Teşekkür ederim, bu denli özenle yapılmış bir mimari anlatımı bulmak gerçekten güç. Başarılar dilerim.

[@TechBuddyTR]

Çok teşekkür ederim, umarım faydalı olmuştur.

[@kaanacar8340]

Emeğinize sağlık gerçekten bu konularda Türkçe kaynak bulabilmek çok zor. Teşekkürler. Umarım devamı gelir. Bizde faydalanmaya devam ederiz.

[@gamzeseker7089]

İlk 2 videoyu izleyerek geldim buraya. Emeğinize sağlık çok faydalı oldu. Başarılar dilerim.

[@ucretsiztakipci6612]

Daha iyi anlatanını görmedim, ağzınıza sağlık!

İlk izlemede sindirmesi zor tabi :) 2. izleme ve uygulamak gerekir. Elinize sağlık.

[@TechBuddyTR]

Evet biraz havada kalabiliyor.

[@suleymancelik1757]

harika çok işime yaradı eline saglık

[@beyazbiyaz]

Çok güzel bir anlatım, teşekkürler.

[@sertunc-k5o]

Harika anlatmışsınız. teşekkürler

[@omerfarukcan3982]

Hocam ağzınıza sağlık. Çok teşekkürler

[@robertmrobo8954]

As someone who's very experienced in Programming, I managed to learn what I wanted to learn with both audio and subtitles turned off coz I wasn't hearing a thing. Programming is a universal language.! Though in future videos, I'd love you to at least include English subtitles, auto-generated ones are super useless.

[@kaanacar8340]

Umarım komple daha detaylı (detaylıdan kastım sipariş ayağıda olan bir video serisi) clean architechture yöntemi ile çeker iseniz çok memnun olurum kendi adıma.

[@aog.tr.6828]

Çok faydalı oldu, teşekkürler.

[@yigit2505]

Çok faydalı hocam, çok teşekkür ediyorum.

[@emrecalbor6480]

Emeğinize sağlık, çok faydalı oldu.

[@TechBuddyTR]

Teşekkürler :)

[@KiyidakiAsk2024]

Efsane🚀🚀🚀

[@ahmetsarkaya9203]

Öncelikle eğitim için teşekkürler. Application katmanında kendimiz bir servis yazarak da aynı işi yapabilirdik. Bu yöntemin bize sağladığı tek fayda Command ve Query ' leri ayırmak mıdır? Başka bir faydası var mı? İkinci bir soru da bu cqrs pattern ' ı generic hale getirmemiz başka entityler eklendiğinde işimizi daha kolaylaştırmaz mı yoksa daha mı karmaşık hale gelir?

[@kemalsen96]

emeğinize sağlık hocam

[@TechBuddyTR]

Teşekkürler :)

[@IrfanSoydan-b3r]

Generic Repository'nin anti pattern olduğu ile ilgili birçok makale ve video var bunların sebeplerini sizin yorumunuzla dinlemek isterim.

[@egemenbahtiyar8675]

Hocam emeğinize sağlık. Bir sorum olucaktı sizlere Caching için ayrıca bir katman mı oluşturulmalı yoksa Application içine mi dahil edilmeli ? Aynı şekilde RabbitMQ gibi queue mekanizmları da mı Application da olmalı ? ve son olarak Test yazmak istersek onu ayrı bir katman olarak eklemek mi doğrudur ? Teşekkürler.

[@TechBuddyTR]

Selamlar, Tüm testler ayrı bir proje içinde olmalı zaten. Onun dışında bu proje çıktığımız tüm noktalar Infrastructure katmanında olmalı. RabbitMQ yu kullanan interface'ler Application katmanında olacak ama bu interface'leri kullanıp gerçekten queue ları veya mesajları yönettiğiniz yer Infrastructure katmanında yer alacak. Caching için ayrı katmana gerek yok. Ama caching'in implementasyonu da yine Infrastructure katmanında olmalı.

[@egemenbahtiyar8675]

@@TechBuddyTR Anladım hocam çok teşekkür ederim.

[@ercanmcpd8656]

Hocam merhaba, HasData kullanımında ilk datayı içeriye neden alamadık?

[@yigit2505]

Hocam merhaba, persistance katmanındaki ServiceRegistration sınıfımızda inmemory db yerine örnek veriyorum mssql kullansak presentation layerdaki connection string ve configuration bilgisine ihtiyacımız oluyor. Bunu nasıl kullanabiliriz bu yapıya uygun olarak? Teşekkürler :)

[@TechBuddyTR]

IConfiguration interface'i üzerinden sağlanabilir. webApi katmanında server bilgilerini config olarak tutup, bu config bilgisini paslayabilirsiniz serviceregistration kısmına.

[@ricardothomas3779]

I am very interested in learning the content of this video. How can I view the subtitles in English?

[@TechBuddyTR]

In some countries, I have absolutely no idea what parameters are, there is an automatically created English subtitle for my videos. On the other hand, I might try to add a subtitle for this video first Turkish and then an English one. But only this video won't help that much unless you watch the previous 2 videos.

[@anonim8680]

Güzel bir anlatım. Yeni başlayan biri sayılırım ve anlamaya çalışıyorum. Yeni bir pattern tanımış da onion architecture araştırırken. UnitOfWork'un üzerine bu tasarım deseni kullanılabilir miyiz? Bu şekilde kullandığımda avantaj ıya da dezavantajı var mıdır? Böyle sormakla umarım yanlış bir ifade kullanmadım :) Bir de görmüş olduğum services katmanı oluşturularak, bu katmandan UnitOfWork'a oradan da Repository'lerimize ulaştığımız yapılar. Bu farklı bir mimariye mi ait yoksa mimarilerde kullanılan bir tasarım deseni mi ya da başka bir şey mi? Onion Architacture baktığımda bahsettiğim bu durum uymuyor gibi geldi bana. Yanılıyor muyum? Umarım geri dönüşünüz olur. Teşekkürler.👍

[@TechBuddyTR]

Merhabalar teşekkürler, UnitOfWork repository lerle birlikte ve onların içinde çalışan bir pattern. Transactional işlemlerin daha yoğun olduğu projelerde daha çok kullanılıyor. Onion Architecture içinde de kullanılabilir. Repository varsa bunun kullanıldığı her yerde UnitOfWork u de kullanabiliriz.

[@mesutsevinc4069]

Hocam benim kafama bir şey takıldı. Onion Architecture mimarisinde dışarıdan içeriye doğru yol izlendiğini belirttiniz fakat video da Infrastrucute klasörü altında bulunan Persistence katmanına Domain' de ki Entity' i dependencie ettiniz. Normalde Persistence katmanından Application katmanına gitmemiz gerekmiyor muydu ? Bu benim kafamı karıştırdı açıkçası. Cevabınızı merakla bekliyor olacağım hocam. 🙏🙏

[@TechBuddyTR]

Selamlar, dışarıdan içeri ulaşırken sadece tek bir seviye gibi bir durum zorunlu değil. Domain modelleri tüm katmanlarda kullanılabilir. Yani kaç katman geçtiğimiz değil de gidiş yönümüz önemli :)

[@mesutsevinc4069]

@@TechBuddyTR Anladım hocam şimdi 😅 çok teşekkür ederim 🙏

[@talhacan9688]

iyi günler, Böyle bir mimaride business roles nereye yazmamız gerekmektedir sizce? Tüm commands and Queries işlemlerini mediatR üzerinden yapıyorsun. Tüm getir, götür işlemleri buradan gerçekleştiği için benim aklıma sadece bu classlarin içinde yapma fikri geliyor ama ne kadar doğru karar veremedim.

[@TechBuddyTR]

Business rule lar application projesi içinde yapılmalı. İster command ve query içinde yapın isterseniz ayrı business servisleri altında yapın. İkisi de olur. Ama önemli olan bu katman içinde olması

[@fatihozturk5400]

Hocam onion architecture da authentication ve authorization da anlatma gibi bir planiniz var mi? Yoksa onion'a ozel anlatmaya degicek pek bi olayi yok mu?

[@TechBuddyTR]

Uygulamanın bütününe bakınca bir özellik gibi görünen ama Domain Driven Design içerisinde yeri olmayan bazı özellikler Cross-Cutting Concern diye biliyor. Exception Handling, Authorization, Authentication, Logging gibi işlemler bu alanda yer alıyor. Bu özellikleri ise Onion Architecture içerisinde Infrastructure bölümünde yer almalı ama özellikle bu videoda değinilecek bir detayı yok.

[@yunusemrealpak6118]

Emeğinize sağlık. Hocam bu videodaki mimariyi kendi projelerinizde de aktif olarak kullanıyor musunuz? Bir süredir Hexagonal Architecture'ı inceliyorum kendi projelerimde kullanmak için. Önüme bu seriniz çıktı ve mimari hoşuma gitti. 2 yıl sonraki düşüncelerinizi merak ediyorum. Hala bu mimari kullanışlı oluyor mu sizin için? Hexagonal Architecture'a nasıl bakıyorsunuz?

[@TechBuddyTR]

Selamlar, Altıgen mimari ile Soğan Mimarisi arasında çok fazla fark yok aslında. Bunların hepsi Domain-Centric yani domain kısmını merkeze alan ve diğer katmanları dışarıdan-içeriye şeklinde bağımlılık yaratacak şekilde konumlandıran yaklaşımlar. Kendi projelerimde Soğan mimarisini aktif olarak kullanıyorum.

[@KiyidakiAsk2024]

çok fazla entity için cqrs kısmını yazacak olsak, features altına product, user gibi dosyalar açıp, altına mı command, queries oluştururuz. Yoksa command altına mı product, user diye klasör mü açarız, yoksa hepsini alt alta yazar mıyız?

[@TechBuddyTR]

Command ve query 2 ana klasör olmalı features altında. Daha sonra bunların altına user, product vs açarız

[@KiyidakiAsk2024]

@@TechBuddyTR çok teşekkürler, videolar baya dolu, mimari konusunda soru soran arkadaşlara yolluyorum.

[@KiyidakiAsk2024]

Bir sorum daha var; birden fazla entity üzerinde işlem yapan bir operasyonumuz olsa, bu operasyonu createCommand kısmında mı yapacağız? Yoksa Service sınıfları tanımlayıp orada mı? Veya başka bir yolla mı? İşi biraz daha büyüse ve başka apiler de kullanılıyor olsa bu back end içinde, bu apilerin referans edilip, kullanıldığı kısım nerede olurdu? şimdiden teşekkürler?

[@TechBuddyTR]

Bu yapıdaki Command veya Query handler metodlarımızı Entity ler üzerinde işlem yapmak için kullanabiliriz. Ekstradan servis katmanı oluşturmaya gerek kalmaz birçok durumda. Bunun dışında başka api'lere bir nuget paketi verilebilir ki bu durumda bu api'nin sahip olduğu endpoint'lerin interface'leri falan bu paket içerisinde yer alırdı. Eğer diğer client'lar dotnet değilse, OpenApi dan faydalanılabilir, Swagger vs verilebilir entegrasyon için. Eğer biz başka entegrasyonlar yapıyorsak, bu entegrasyonlar infrastructure katmanında olurdu.

[@KiyidakiAsk2024]

@@TechBuddyTR çok teşekkürler, Harika bilgiler. Bu yapıya, dinamik filtreleme yapısı ekledim, >, like, in, beetween gibi filtreleme durumları için, birde dinamik bir order by. Yine entityler arası dinamik bir join aracı… bu mimari yağ gibi akıyor. Kod yazmak, bişeyler eklemek çok kolay… klasik request/response mimarilerine göre çok üstün. Şu ana kadar daha sade, basit, kod yazdıkça o dingin halini koruyabilen bir mimari daha görmedim. Çok teşekkürler. Bu son yorumunuz daki tavsiyelerinizde muhteşem… zaman ayırıp cevapladığınız için ayrıca teşekkür ederim.

[@TechBuddyTR]

Bu kadar uğraşın sebebi aslında günümüzü değil de geleceği kurtarmak. Gelecekte bu projede değişiklik yaptığımızda en az uğraşla bunları yapabiliyor olmak için kurguladığımız mimarileri bu kadar iyi tasarlamaya çalışıyoruz. Sizin örneğinizdeki gibi, yeni metodlar ekleyerek hiç bir şeyi bozmadan yolumuza devam edebiliyoruz.

[@KiyidakiAsk2024]

@@TechBuddyTR en başta mimarilerin hepsi sade ama sonra korkunç sonlanabiliyor. Bu mimari ile 10 gündür baya kod yazdım. Gram kötü hissettirmedi. Çok teşekkür ederim. Ddd de kayboldum dediğim yerden aydınlığa çıktım.

[@unsalsenturk2120]

🎉

[@gurdamaci]

MediatR' a neden gerek duyduğunu anladım. Ama çözüm olarak Product' a özel olan repository' de GetAllProduct() fonksiyonu yazıp dönüş tipi olarakta istediğimiz viewModel' i verseydik. Repository' den productları gene çekip mapleme işlemini burda yapsaydık aynı işi görmez miydi? Bu anlattığım senaryoyu düşününce MediatR gereksiz gibi geldi bana. Başka avantajları da mı var bilmiyorum tabi.

[@TechBuddyTR]

Mediator pattern'in en önemli artısı katmanlar arası bağlantıyı ortadan kaldırmak. Biz command'i fırlatıyoruz ve bunun handler'ı hangi katmanda bizi hiç ilgilendirmiyor. Geri dönüş tipi de dinamik olduğu için onu da belirtmek durumunda kalmıyoruz özellikle.

[@gurdamaci]

@@TechBuddyTR teşekkürler

[@KiyidakiAsk2024]

@@TechBuddyTR bu mimaride en çok bunu sevdim.

[@oguzhankomcu2031]

Hocam merhaba cevap verirseniz de sevinirim. Bu design patternı yeni öğrenmeye başladım ve yeni bu projemde de bu patternı kullanmak istiyorum. Bu cqrs patternı uygularken yapılan klasörleme bu şekilde mi olmalı ? Yani "Features" klasörünü ilk defa gördüm . Projemde business mantıgında hareket etmek isteediğim için nasıl bir klasörleme olmalı ?

[@TechBuddyTR]

Ağırlıklı olarak klasör yapımız bu şekilde oluyor cqrs kullanırken. Onion architecture da business kuralları application katmanına gittiği için bu yapı da korunmuş oluyor

[@oguzhankomcu2031]

@@TechBuddyTR peki handler sınıfını query sınııfnın içinde oluşturmamız yanlış olmaz mı ? Bunu başka yerlerde ayrı ayrı oloması gerektiğini gördüm hemde SOLİD prensiblerine uymak açısından doğru mu ?

[@TechBuddyTR]

@@oguzhankomcu2031 handler ları query sınıfı içerisinde oluşturmuyoruz ki. Dediğiniz gibi aynı sınıf içerisinde olmaması lazım. Zaten her şeyden önce bunlar ayrı ayrı sınıf olarak tanımlanıyor

[@oguzhankomcu2031]

@@TechBuddyTR hocam burada kendinizde söylüyorsunuz ondan dedim 4:00 commandda da aynısı var 28:45

[@TechBuddyTR]

@@oguzhankomcu2031 :)) ben videoları karıştırdım kusura bakmayın, evet ayrı ayrı tanımlamak gerekiyor bu class ları. Bu pattern i kullandığımız son projelerin videoları izlerseniz, orada da ayırdığımızı görebilirsiniz :)

[@ermekbakyt5507]

Project mastere push olmamis! Push yapabilirmisiniz?

[@TechBuddyTR]

Merhabalar, github.com/salihcantekin/OnionArchitectureApp_KZbin adresinden erişilebilir durumda aslında. Daha önce push'lamıştım

[@ermekbakyt5507]

@@TechBuddyTR yanlis yazmisim ozur dilerim! Demek istedigim son kodlar yokmus!

[@TheRaistland]

Teşekkürler. Gerçekten çok kıymetli bilgiler

[@hikmetfazila6299]

emeğinize sağlık hocam