@MilanJovanovicTech
Good to see you back 🔥
@misonosenpai3168
Now this problem is fixed on EF core 8, but this is a very helpful tutorial, i can't find any course that teach about DDD better than your course
@poddev
Yes I agree is nice to have our ids properties strongly tipped in the other hand sometimes I feel this is too over engineering which is the opposite of clean code.
@jorgeurielcarballohernande9886
Wow! I started this amazing serie about CA and DDD and I can't stop. Congrats for your job. No words to describe the effort and the passion put in this. Again thousand thanks @Amichai 👌🤓.
@shoooozzzz
Ahhhhh yeah, he's back! So happy we get more top tier content.
@alexandercarlsen2038
I usually keep the inner identifier private and implement implicit and explicit conversions to string or whichever inner type we are using. This way, all of the domain code doesn't know, but any dependencies (like EF or something like a httpclient can use the string as needed)
@carloswinstonjavierllenas3117
Many thanks. I found myself Laughing Out Loud when you reached the not recommended solutions because I tried the first three in my pet project where I'm trying all you taught us in these videos, and discarded the first two because of the SAME reasons.
@qaphuikpoh
Good to see you back 🎉
@davemasters
Back with a bang! I struggled with this and ended up succumbing to your 2nd bad solution. Look forward to going back to implement this solution!
@prashlovessamosa
Long time pal.
@jamesevans6438
Welcome back - I've never modeled a domain to this extent using EF Core so not hit the problem you were facing but I like the solution, seems nice and clean, no real downside?
@MrDiscussion
My thought process it that the problem is with EF, which is a tool for our infrastructure layer and therefore our domain should not be responsible for the solution of the problem but rather the infrastructure itself. Therefore for me, the most suitable solution of the ones you mentioned is the first one. This I think also makes it easier if in the future EF decide to support this to change the infrastructure layer.
@Maxim.Shiryaev
IMHO, the main problem is an existence of Id properties in the domain objects. If we've got rid of foreign keys in dependent objects using shadow properties, for me it's just absolutely necessary to make Id properties shadow as well. No Id - no problem. Ids are DB realm concept, not object one. What do you think?
@Codewrinkles
Nice one. Welcome back!
@atlesmelvr1997
It's not a common bug to put the wrong id in the wrong column, and you can even enforce to write them as (userId: userId, tenantId: tenantId) to read it better. And the penalties you get is a lot worse than what you get (that's not needed). You have less readability, more code to write everywhere, it's slower and use more cpu. All this for a non problem.
@LoZioIAR
Great!! You are back!!
@S3Kglitches
Your domain-layer objects should not be your EF models. Breaking single responsibility principle. 8:00, 8:45 Mapping is overhead but that's the trade-off for robustness and having an anti-corruption layer. 9:15 Creating a mapping cannot introduce bugs compared to switching IDs in the function arguments which definitely will and these will be very hidden bugs.
@vagnerpadilha3485
Amazing to see you again. A question. why do you prefer StronglyId has a "class" type Wouldn't "record struct" or "struct" be preferable? To lower the GC pressure?
@sphrtehrani
Hi, great series. In DDD we use GUID for Id type because entities ids must be unique across our domain. But in database using GUID as primary key (with clustered index) has performance issue specially in heavy insert scenarios because of randomness of GUID Ids. What can we do about it?
@ahmedrizk106