What is DDD | Domain Driven Design
HTML-код
- Опубликовано: 13 май 2021
- In this video, I explained both theoretical and practical details about Domain-Driven Design, a technique that has been used frequently in the modern software development world. I have also included the terminology of DDD and the details of what they are used for in this video.
Наука
Emeğine sağlık diyip geçmeyin. Belli ki ciddi mesai harcanıyor, ücretli abone olun. İnsanlar şevklensin, kaynak sahibi olsun ki işi devam ettirebilsin.
Arkadaş; sen ne kadar çok muhterem bir yazılımcısın güzel bilgiler paylaşıyorsun. Bilgine güç eline sağlık ne güzel emek bu videolar. Birde alttaki yorumlardaki sorulara hızlı cevap vermen takdire şayan.
Çok teşekkür ederim güzel yorumlarınız için. 😊
Hoş bulduk
Hocam kanalınız o kadar mükemmel ki gerçekten bu kadar geç keşfettiğim için üzülüyorum Teşekkür ederim
Gerçekten anlattıklarınız çok kıymetli bilgiler. Sayenizde makalelerde okuduğumuz şeyler somutlaşıyor. Uygulanabilir oluyor. Emeğiniz için gerçekten teşekkür ederim.
Kanalın üyelerinin zaten çoğunluğu katılmış yorum yapanlardan gördüğüm.
İlk defa bi kanala üye oldum ben de. Etrafında güzel bir yazılım topluluğu oluşuyor ne güzel.
Çok teşekkür ederim. Umarım güzel bir topluluk oluşturabiliriz
Sizi yeni keşfettim. Harika içerikler mevcut. Mükemmel ötesi. emeğinize sağlık
Teşekkür ederim, iyi seyirler
Hocam çok kıymetli işler yapıyorsunuz. Elinize sağlık.
Teşekkürler. Çok başarılı bir anlatım olmuş.
Hocam seni yeni keşfettim. Hafta sonu da Beşiktaş'ta toplanıyormuşsunuz. İstanbul dışındakilerin gözü yaşlı :(
Güzel anlatım olmuş hocam teşekkürler.
Elinize sağlık hocam.
Emeginize saglik cok guzel ve degerli bir icerik olmus 💯
Teşekkür ederim. İyi seyirler.
Eğitim için teşekkürler hocam.
Gerçekten fark yaratıyor ve çok kaliteli içerik üretiyorsunuz. DDD anlatan bir çok video var ama genelde anlaşılabilir olmuyor ya da çok uç örnekler veriliyor. Micro service video serinizde bu videonun devamını sabırsızlıkla bekliyor olacağım. İyi Çalışmalar.
Güzel yorumlarınız için teşekkür ederim, umarım video faydalı olmuştur.
Ubiquitous Language'ın ne kadar önemli bir konu olduğunu size şöyle bir örnek ile anlatayım. Yıllar önce yeni çalışmaya başladığım bir oyun projesinde işveren sürekli "dataları ve data altyapılarını iyileştirmemiz gerekiyor" gibi söylemlerde bulunuyordu. Projenin dataları da gerçekten çok saçma bir şekilde tutuluyordu. Refactoring sürecine data katmanından başladım ve gayet de iyi oldu. Günün sonunda benim yapacağım işler zaten yapılacaktı bir kayıp yoktu fakat işverenin data dediği şey; 3rd party analitik servislerine (firebase, game analytics vs.) oyunun metriklerini ölçmek için gönderdiğimiz parametrelermiş. Yazılım geliştirmenin iletişime dayalı sosyal bir süreç olduğunu unutmamak lazım :)
Kesinlikle haklısınız. Çok güzel bir örnek :)
Sarsıldım
2 ay önce gelip yorum yapmıştım şimdi tekrar izledim ve sonunda anlamaya başladım bazı teknikleri :D
Bu yaklaşımdaki yöntemler bu zamana kadar öğrendiklerimizden biraz farklı olduğu için alışmanın zaman alması gayet normal :-)
Like attım abonede oldum sağolun teşekkür ederim!
hocam senin anlattığın videolar niyeyse tak oturuyor başkalarını izlediğimde kafa karışıyor...tebrik ederim sizi
Teşekkür ederim :)
@@TechBuddyTR sevgili hocam...mikroservis eğitiminiz gayet güzel ve anlaşılır...Burada benim kavrayamadığım eğitimin dışında bir nokta var malesef. Oda dağıtık bir mimari yapısında örneğin bazı stok hareketlerinin farklı servislerde ve farklı mongo kullandımn ben mongodb de tutuyorum...api tarafında bir bilgi istediğimde bu bilgilerin bir kısmı 1 numaralı hareket microservisinde bir kısmıda 2 numaralı hatta 3 numaralı microserviste. Dolayısıyla ui tarafında bu bilgiyi gönderebilmem için 3 farklı microservisten bilgileri taşıyıp birleştirip göndermem gerekecek burada nasıl bir teknik kullanılması gerekli. Bu konuda cahilim...microservis video eğitiminize bu konu ile ilgili bir çalışma ekleyebilirseniz inanılmaz aydınlanmış olacağım veya olacağız. Saygılarımla iyi çalışmalar
Hocam sizi Onion Architecture yi araştırırken keşfettim. Harikasınız.
Fark yaratıyorsun 👏
Umarım faydalı olmuştur.
Harika
Teşekkürler
entity: bir (identity)e sahip, yani id (property)sine sahip (class)lar 7:45
value object : (identity)e ihtiyacı olmayan 8:30
aggragate root : 9:20
(IAggragateRoot)ta ne vardi 10:30 mantığı
20:30 markup interface (interface)in içi boş sırf işaretlemek için IAggregateRoot kullanılıyor şimdilik
31:35 generate const
hocam elinize sağlık
Umarım faydalı olmuştur 😊
Teşekkürler hocam...
DDD; n-tier, onion yada hexagonal gibi katman yapılarını dayatmaz. Daha core seviye olan domain katmanını nasıl tasarlayacağınızı anlatır. Burada hangi mimariyi kullanacağınız size kalmış.
elinize sağlık
Teşekkür ederim. İyi seyirler.
Emeğine sağlık
Umarım faydalı olmuştur 😊
Merhabalar, kalıcı bir çözüm hiçbir zaman olamaz ama daha esnek bir çözüm mümkündür ama her şey eninde sonunda eskir ve ayak uyduramaz.O yüzdem BPM ya da workflow yaklaşımlarıyla harmanlanmış, gelişmiş arayüzü olan çözümler çok daha esnek kullanım sağlar. Tabiki bu yaklaşımlarda DDD ne kadar uygulanabilir tartışılır.
Hocam cok bilgilendirici bir video olmus, cok tesekkurler. Benim sormak istedigim, OrderModels'teki Order'in constructorunda business logic kullanmak bir anti pattern olusturur mu?
Ddd de oluşturmaz :) ama çok fazla kural olacaksa bir domain servis oluşturulup o kullanılabilir
@@TechBuddyTR Cok tesekkurler.
@@TechBuddyTR Hocam merhaba. Yanlışsam düzeltin lütfen ama kafamı kurcalayan bir şey var. Order bir entity'i yani veri tabanındaki bir tabloya denk geliyorsa, bu class'ın sadece veri tutması görevi gerekmiyor mu? Yani en ufak bir if bloğu dahi olsa yazılan "iş kuralı" SOLID'in S'si ile ters düşmüş olmuyor mu? Eğer DDD bize işlemlerin AggregateRoot'lar içinde yapılmasını zorunlu kılıyorsa bunu muhakkak, bir kaç ufak iş kuralı dahi olsa servislerle beslememiz gerekmez mi? Ya da generic bir AggreageRootService where T : IAggreagateRoot gibi bir markup service interface düşüncesi ile iş kurallarının ApplicationLayer'a taşınması abes mi olur? Açıkçası hem data tutup hem iş akışına katkıda bulunan bir classın SingleResponsibility'ye aykırı olduğunu düşünüyorum. Ha DDD SOLID'i savunmuyorsa ona bir itirazım yok :)
Value Object tanımını tekrar gözden geçirmelisiniz. Value Object bir data transfer objesi değildir. Bu konuda kafa karışıklığı özellikle Java dünyasında hakim olmuş, immutability eşittir value object mantığıyla bakılmış. Data transfer objelerini immutable yapmayı tercih edebilirsiniz ama bu tam anlamıyla bir value object olduğu anlamına gelmez. Bu konuyla alakalı Martin Fowler'ın Value Object makalesini okuyabilirsiniz. Kendisi şöyle ifade ediyor: One source of terminological confusion is that around the turn of the century some J2EE literature used "value object" for Data Transfer Object. That usage has mostly disappeared by now, but you might run into it.
Yorumumunuz için teşekkür ederim ancak veri taşıdığımız obje dememin sebebi efcore ile birlikte bu objeyi Order içerisinde ayrı bir class gibi düşünüp ama veritabanında ise aynı tabloda farklı alanlarda saklayacak olmamız. Efcore içerisindeki OwnedType olarak tanımladığımız zaman tam olarak bu işi yapacak
@@TechBuddyTR Bu konuyu anemiklik üzerinden değerlendirirseniz daha iyi anlaşılacaktır. DTO'lar herhangi bir katmandan katmana veri taşımak için kullanılırlar. Value object'in DDD tanımı ise AggregateRoot içerisinde varolur ve anemik olmak durumunda değiller, yani kendi iş koşullarını yönetebilirler. Ek olarak; AggregateRoot ile Entity aynı obje olmak durumunda değil, bu şekilde kullananlar olduğu gibi farklı objeler olarak da değerlendirilebilir. Ben kişisel olarak farklı modeller olması taraftarıyım. Çünkü AggregareRoot'un ORM bağımlı olmaması ve entity'nin anemik olmasını savunanlardanım. Entity'ler bana göre sadece database objeleri olarak varlıklarını sürdürmeliler.
@@Imploser Aslında bence de ayrı olmalılar ancak ORM bağımlılığı dediğimiz şeyin tanımı günden güne değişir hale geldi. İster EF kullanın ister kullanmayın veritabanı için bir şeyler kullanıyorsanız veya kendiniz yazıyorsanız öncelikle proje sonra da yazılımcılar için hayatı kolaylaştıran yenilikler eklemek gerekiyor ki EF5 ile DDD ye de uyum sağlayabilmek için bunu çok güzel bir şekilde yapmışlar. Ama bildiğimiz gibi DDD veya buna benzeyen bir çok yaklaşım ve bu yaklaşımların tecrübeleri ne bir video da ne de bu kadar kısa sürede anlatılacak şeyler değil. Elimden geldiğinde kendi kişisel tercihlerimi de bir kenara bırakarak kendime örnek olarak aldığım proje veya insanların da fazlasıyla kullandığı teknikleri anlatarak ve bunu yaparken de açıklayıcı olmak niyetindeyim.
@@TechBuddyTR ORM bağımlılığı konusunu şöyle düşünebiliriz. Örneğin DDD ile başladığınız bir projede DB olarak MsSql tercih ettiniz. Proje geliştirildi ve canlıya çıktı, üzerine birçok feature yazdınız. Sonradan farkettiniz ki aslında sizin ilişkisel veri tabanına ihtiyacınız yok ve NoSql'den daha iyi verim alacaksınız. NoSql tabanlı MongoDB'ye geçiş yapmak istediniz. Kullandığınız ORM de MongoDB'ye destek vermiyor veya veri yapısında değişiklik ihtiyacınız oldu. Sizin tüm iş koşullarını yönettiğiniz AggregateRoot üzerinde böyle bir değişiklik yapmak hem zahmet verici hem de migration ihtiyacı doğurabilir. Bu nedenle domain modelinizin framework bağımlılığı getirmiyor olması sizin için bir avantaj. Özellikle anotasyon bazlı entity tasarımlarında bu daha büyük bir problem olabilir. .NET tarafında bir çok ORM'in fluent yapıları mevcut, bu bir avantaj getiriyor size ama bakın yine ORM bağımlı bir avantaj. Mesela DB değil, ORM'in performansından memnun kalmadınız, EFCore yerine Dapper tercih etmeniz gerekiyor, yine ORM bağımlı aggregate tasarımınız etkilenebilir. Başka bir örnek; AggregateRoot üzerinde database'e yazmak istemediğiniz in memory kullanacağınız nesneler olabilir, bu da aggregate root üzerinde kalabalık yaratıyor. Yada bir value object'i tablo olarak tutmak yerine sadece id'sini tutmak isteyebilirsiniz ama domain üzerinde obje olarak değerlendirmek size daha yönetilebilir bir yapı sağlayabilir. Son geliştirdiğim projeler java'da ve Hibernate kullanıyorum. Java'nın aspect oriented tarafı daha kullanışlı olduğu için anotasyon bazlı entity tasarımları tercih ediliyor. Bu durumda domain'e yine teknoloji bağımlı geldi. Temelde dil ve teknoloji bağımlılığından uzak bir domain modellemesi hem daha yönetilebilir, hem de kolaylıkla evrilebilir bir domain tasarımı getirecektir diye düşünüyorum.
@@Imploser Buradaki konu yine Orm bağımlılığı olmuyor aslında çünkü bir bağımlılığı kaldırabilmek için repository pattern ler tercih ediyoruz. Eğer siz Domain'inizi nasıl düzenleyeceğinize karar verdiyseniz ve bunun doğru olduğunu düşünüyorsanız ister orm kullanarak oracle'a bağlanın isterseniz custom bir context ile mongo ya. Ama Aggregate tarafının sistem içerisindeki başka bir parçaya bağımlı olmaması gerek, katılıyorum o konuda. Bu sebeple kullanılan pattern ler değiştirilebilir veya yeni geliştirmeler eklenebilir kullanılan sistemlere. Aggregate'lerin Entity olarak tanımlanması bence yine Orm bağımlılığı getirmiyor çünkü bu aslında ORM'i nasıl kullandığınız ile de alakalı. Ama en doğrusu Aggregate için Entity i ayırıp sadece Aggregate içerisinde referans olarak kullanmak veya aradaki iletişim yöntemini geliştirmek olacaktır
hocam sevgiler, factory design pattern konusunu da işlerseniz çok mutlu olurum. teşekkürler.
Videosu geldi, şu an sadece katıl üyelerine özel. Yakında herkesin erişimine açılacak.
DDD epeydir ilgimi cekiyordu. Emeginize ve zahmetinize saglik. Mimarisi cok ilginc kurgulanmis. Ancak bir o kadarda merak uyandirici. Kurgulanmasi zahmetli gorunsede, buyuk projelerde kesinlile verimli gibi gorunuyor. Anladigim kadari ile aslinda Aggregate lar ayni zamanda bir Entity ozelligi de tasiyorlar sanki!? O halde Aggregate classlarimizi hem Entity hemde Aggregate dan turetmek yerine, AggregateRoot u Entity'den tureyecek sekilde tasarlamak mumkun olabilirmi?
Aggregateroot içerisinde iş kurallarımız da yer alıyor. Bu kuralları yönetmek normalde entity'lerin görevleri değil bildiğiniz gibi. O yüzden AggregateRoot'larımızı entity den türetmiyoruz. Entity'lerimiz ve Aggregate'lerimiz hem anlam hem kavram bakımından birbirinden farklı objelerimiz yani
Emeğinize sağlık. Bir düzeltme yapmak istiyorum. Repository application değil domain katmanının bir elemanıdır. Repository interfacelerini domain katmanında, implementasyonlarını ise infrastructure katmanında yapmalıyız.
Neden? Böyle bir zorunluluk temel olarak yok. Bu sizin ve gördüğünüz örneklerin ve yaklaşımların sonucu. Bu yorumu okuyanlar büyük ihtimalle aynen böyle düşünecek. Okunabilir kod yazmak zordur ondan bazı standartlar vardır diyebiliriz ama bu zorunluluk değildir. bence hatalı bir şey yok.
@@k2an, dogru bir ddd yaklasiminda repository interfaceleri kesinlikle domain katmaninin bir elemanidir. Yine ddd’ye gore application katmani domain katmanina bagimlidir. Tersi olsaydi domain katmanindan repository interfacelerine erisim olmayacakti. Ve bizler bir diger domain katmani elemanlari olan entity/aggregate root ve ozellikle domain servislerden repository’lere erisemeyecektik. Sizin yazdiginiz programlama dili heralde circle referans destekliyor?
hocam DDD gibi kompleks bir yapıyı kısa sürede bu kadar detaylı şekilde anlattığınız için teşekkür ederim. DDD ile ilgili başka videolarınızız var mı? varsa nasıl ulaşa bilirim? teşekkürler.
Ddd nin uygulanması videosu var Microservice video serisinde :))
@@TechBuddyTR bilgi ve hızlı cevabınız için teşekkür ederim.
Validation'ları Entity içerisindeki constructor da yaptık. O zaman fluent validation vb. gibi yapılar ile handler'larda bir validasyon yapmamıza gerek kalmıyor değil mi?
Bir de iş kuralları gereği veritabanına gidilmesi gerekiyorsa, örneğin yeni bir kategori ekleneccek ve katerogi adı tekrar eklenmemeli gibi veya buna benzer. Buradaki iş kuralını Handler'da mı yapmak gerekir yoksa entity içerisinde mi, entity içinde yapılması için entity nin repository'e bağımlı olması ve dışardan set edilmesi gerektiği için olacağını düşünmüyorum fakat her okuduğum yazıda iş kuralları domain katmanında yapılır yazıldığı için kafam karıştı.
Bu yapıda benim en çok kafamı karıştıran şey kuralların nereye yazılması oluyor. Kendimce şu şekilde yapıyorum. Kural veritabanı bütünlüğünü korumak için yazılıyorsa veya işin yöneticileri tarafından (müdürler ceolar vs) değiştirilemeyecekse hatta haberileri bile olmasa olur kuralları ise domainde diğer bütün kurallar, bana söylenenler şöyle olsun böyle olsun gibi kurallar applicationda.
Selamlar hocam, Order tablosuna IAggreateRoot miras verdik peki Buyer, sınıfın'da IAggreateRoot ile miras vermemiz gerekmezmiydi yoksa kaçırdığım biryer mi var aceba?
Selamlar, Order tarafında İş Kurallarımız vardı o yüzden ayrı bir domain olmak durumundaydı ancak aynı şey Buyer için geçerli değildi. O kendi başına bir domain değildi sadece bir Entity'ydi. Ancak microservice projesi video serisinde Order projesi içerisinde Buyer tarafında IAggregateRoot olarak işaretledik çünkü orada bir domain görevi görüyordu Buyer :) O videoyu izleyebilirsiniz.
Hocam bu kadar şey anlattınız ama benim en dikkatimi çeken şey
Aggregate(x,y)=>x^y oldu.
araştırdım ama anlayamadım. int int operator yazıyodu. kendim denedim 1^4 gibi 5 sonucu döndü. ne işe yarıyor bu ^ ?
Teşekkürler
Selamlar, oradaki ^ işaretnin anlamı "Özel Veya" anlamına geliyor. İki integer için özel bir şart kontrolü sağlıyor. Detaylı açıklamayı şuradan bulabilirsiniz.
www.csharpnedir.com/articles/read/?id=180
Hocam burada buyer yoksa neden ekliyoruz. Buyer zaten sistemde kayıtlı değil midir? Yoksa demekki sistemde kayıtlı kişiyi alamamışızdır ve hata dönmeliyiz diye düşünüyorum.
Bu tamamen sistemi nasıl tasarladığınıza göre değişir. Kullanıcı mutlaka olmalı ve sipariş işlemi öyle başlamalı diyebiliriz. Bu durumda bahsettiğiniz gibi olmalı. Diğer yandan da kullanıcı giriş yapmadan sipariş verebilsin ama ben bunun kaydını tutabilmek için kayıt edeyim de diyebiliriz. O zaman da bu videodaki gibi olabilir.
Hocam elinize sağlık güzel video ama sistem değişikliğe duyarlı denmekte bakınız küçük bir entity değişiminde bile 20 tane yer değiştirdik :) biraz gereksiz gibi geldi sahsen
şöyle düşünmek lazım. Bir entity değiştiriğinde yaptığımız tüm değişiklikler o domain içerisinde yapıldı. İşlerin çok büyüdüğü, her domain'ini ayrı takımlar hatta belki de firmalar tarafından yapıldığını düşünün. Bu durumda yaptığımız değişiklik sadece bizi ve takımımızı ilgilendirecek. Başka bir domain'de değişiklik yapmak için, başkalarını beklemek ve etkilemek zorunda kalmıyoruz :)
Takıldığım bir nokta var.
ben bir order oluşturduğumda, neden gidip o userName içerde varmı yokmu diye kontrol ediyorum? buna neden ihtiyaç duyuyoruz?
şöyle örnek vereyim. bir uygulamaya login olunca zaten o uygulama login işlemleri sırasında benim user bilgilerimi alıyor. JWT aktif ise istediği yerde alıp kullanabilir. yani jwt aktif olduğu sürece benim user bilgilerim orderda kullanılacak. tamam o zaman neden burada o userName varmı yokmu diye bir kontrole gidiyorum?
anlatımınız gayet başarılı. bu takıldığım noktayı açıklarsanız çok sevinirim. teşekkürler.
Videoda da açıklamaya çalışmıştım. Eğer zaten merkezi bir Authentication yapımız varsa elbette gerek yok kullanıcı bilgisini sorgulamaya. Order ile ilişkilendireceğimiz bilgileri JWT içerisinde veya erişebileceğimiz başka bir yerde varsa gidip oradan da alabiliriz. Ancak bu örneğimizde böyle bir yapımız yoktu :)
@@TechBuddyTR Anladım bu sadece spesifik bir örnekmiş ve senaryodan senaryoya değişebilir. :) evet şuan tamamen anladım. teşekkür ederim :))
32:15 Hocam bu DDD Solid'e aykırı olmuş olmuyor mu ? Order sonuçta bir entity ama içinde işlem yapılıyor.
SOLID'in hangi prensibine aykırı oluyor?
@@TechBuddyTR Single responsiblity. entity içinde method kullanıyoruz. order item ekliyoruz order entity'si içinde işlemleri yaparken if kontrolleri de ekledik business ruleları.
İlk defa bir proje oluştururken src klasörü oluşturulduğunu gördüm .Nette. DDD'yi yeni yeni tanımaya başlıyorum. Ama video o kadar üst seviye olmuş ki hiçbir şey anlamadım valla. Uzun zamandır yazılım geliştiriyorum ama bu video bana o kadar ağır geldi ki anlatamam. Hiç alışık olmadığım, standart olarak gelişirdiğim yöntemin o kadar uzağında bir yapı ile çalıştınız ki videonun en başında hafif motor yağım ısınmaya başlamıştı, mediatoru kullanmaya başlayınca iptal oldum. Katmanlar bile hiç alışık olduğum şekilde değil. Hani DataAccess, Entities, Business gibi katmanlar oluştururduk ya, burada hiç kullanmadınız. Mesela validasyon işlemlerini neden Business adında bir katman oluşturup orada yazmak yerine neden direkt sınıflar içinde uyguladınız hiç anlayamadım. BaseEntity sınıfına notification collection eklediniz onun hala mantığını anlamaya çalışıyorum. Ki bundan önce oluşturduğunuz event ve event handlera hiç kafam basmadı. 10 yıldan fazla bir zamandır yazılım geliştiriyorum ancak bu videoda kullanılanlar şu an kendimi sorgulamamı ve sanırım bu iş bana göre değilmiş bıraksam mı diye bir düşünceye soktu. Yazılıma yeni başlayan biri gibi yabancı kaldım resmen. Başvurduğum bir çok firma hep domain bilgisi soruyor. Nedir bu Domain Driven diye araştırmaya başladım öğrenmek için ve buraya geldim. Sanırım bu video ile umudumu yitirdim :(
Emeğinize sağlık.
Merhabalar, Öncelikle DDD bizim bu zamana kadar kullandığımız yapıların hizmet ettiği şeye farklı bir yoldan hizmet ediyor. Herkes bunu bilmek veya kullanmak zorunda değil ama piyasada fazlasıyla kullanılmaya başlandı artık DDD. Çok faydası görüldü çünkü ama zaman açısından biraz maliyetli olduğu için her projede mutlaka kullanılması gerekmiyor. Hatta bazı durumlarda kullanılmamalı.
Business rule ları ayırdığımız anda Bounded Context dışına çıkmış oluyoruz ve o yüzden DDD kuralını ihlal etmiş oluyoruz. O yüzden tüm kontrol Aggreator sınıfımızda oluyor.
Kendinizi sorgulamanıza veya bundan vazgeçmenize gerek yok bence. İnternette çok kaynak var ddd ile ilgili. Kabul ediyorum bu zamana kadar öğrendiklerimize ters bir senaryo ama öğrenmek bir şey kaybettirmez bence :-)
@@TechBuddyTR çok teşekkür ederim hocam 🙏 😊bir mülakatta domain model, domain driven design kullanıyor musunuz nedir kullanıyor musunuz diye sormuşlardı. Sadece nette okuduğum tanımlardan aklıma gelenleri söylemiştim. Ancak bir soru daha sordular. Aggregator kullandınız mı ne işe yarar diye. İşte bu soruya tek kelime cevap veremedim. Hala veremiyorum çünkü bir türlü anlayamıyorum ne işe yaradığını. Siz de video bahsetmişsiniz. Bu terimin burada tam olarak ne anlama geldiğini ne görev gördüğünü hala anlamadım. Belli ki önemli bir konu. Tam olarak nedir hocam Aggregator dedikleri şey? Lütfen 5 yaşımdaymışım gibi biraz anlatabilir misiniz? 😊😊😊
OrderItem neden ValueObject değil?
OrderItem bir Order içerisinde birden fazla olabilir. Birden fazla olduğu durumlarda da bir kimliği olması gerekir. Kimliği olan objeleri ValueObject olarak tasarlayamıyoruz.
DFd dosyasını açmak için bir program varmi
DDD dosyasi
source code'a erişme şansımız var mıdır acaba?
Videonun açıklamalar kısmına eklenmiştir link.
@@TechBuddyTR teşekkür ederim
Biraz karmaşık mı bana mı öyle geldi?
DDD nin kendisi biraz karmaşık :) Elimden geldiği kadar sadeleştirerek anlatmaya çalıştım
Value Object'i record yaparsan oradaki metotlara veya çoğuna ihtiyacın olmuyor zaten eşitlik kontrolü yaparken structural olarak karşılaştırıyor ve zaten kendisi immutable olduğu için onun için de ekstra bir şey yapmana gerek kalmıyor bu durumda işaretlemek için bir interface yeterli olur gibi görünüyor.
ValueObject yerine direk record kullanılmalı. .NET 5 te vardı diye hatırlıyorum zaten şuan .NET 6 . Equality overridelarına gerek kalmaz. Saygılar.
Evet record kullanılabilir ValueObject yerine ama record'lar bellekteki Heap bölgesinde tutulduğu için çok yüksek sayıda istek alan metodlarda kullanmaktan biraz kaçınmak gerekebilir :)
@@TechBuddyTR stack demek istediniz sanirim, heap dinamik bellek icin gecerli c#taki struct olmayan veya stackalloc ile yaratilmayan tum objeler heapte yaratılır ve yavastir. Stack cok hizlidir evet limitlidir ama mb boyutlarinda bir limiti mevcut. Bir value objesi bi requestte bu boyutlara geliosa zaten sıkıntı record da degildir :)
@Gordon Freeman evet stack demek istedim :)
Doğru söylüyorsunuz sıkıntı başka yerdedir bu durumda ama yine de bir developer olarak bunlara hakim olmak önemli.
Stack hızlı evet çünkü obje kullanıldıktan sonra temizleniyor ama dediğiniz gibi limitli. Çok yüksek kullanımlarda dikkatli olmakta fayda var :)
@@TechBuddyTR okuyacaklara not olsun: artık record class ve record struct türleri ayrıldığı için heap'te tutulmak istenen türler için record class kullanılabilir.