OMG thank you so much! I really really appreciate it, I want you to know that your donation means the word to me. I love you, and I'll see you at dinner 😘
Curious to hear what you think! Do you have experience with modeling a domain? Do you have a different approach? Do you have different rules of thumb? Are you new to DDD? Do you have any questions regarding any of concepts?
@@amantinband I have a project at the university and I want to model it using DDD. I've looked at a lot of information about this, but your videos are awesome. Structured, useful information, and even with project examples
I struggled and learned a lot bending EF for DDD. There is a lot to talk about and practically no advanced examples available so you can expect some deep dives 👍🏼
@@amantinband That is the same as my experience, and yes, there really is not much material out there for it. But EF core has come along way in recent years allowing for constructors, automatic mapping to encapsulated backing fields, 'OwnsOne/OwnsMany' etc. Before these features the only way was to have a separate data model from the domain model which adds massive overhead.
Thank you for your videos,, I just wanted to share with you that your voice is distorted - also in your previous video was the same. You changed something?
The aggregate modeling steps are misleading and/or confusing. Not all entities have to be defined as aggregates. Why merge different aggregates into one aggregate? Aggregates have their own invariants, so do entities, but using these terms interchangeably leads to confusion. What does merging them achieve? Did you mean merge different *entities* to form aggregates in order to enforce a new aggregate's invariants (e.g. move Reservation *entity* inside the Dinner entity to form a Dinner aggregate that enforces invariants that use both these entities)?
Perhaps I could have been clearer on this topic. The steps I suggest in the video are: 1. Treat each entity as if it is an Aggregate Root 2. Merge Aggregates when there are constraints. Constraints can be: 1. Invariants 2. Eventual consistency cannot be tolerated Does that make sense?
What if i make DinnerAggregateRoot and DinnerReservationsAggregateRoot with same id or with relation by having DinnerReservationsId in DinnerAggregateRoot?
hi Amichai, I assume you made a bunch of videos where the clipping of your audio happend and you publish this videos now on a weekly basis. If this is the case, please ignore this comment. If not: you're still clipping :/
I cant wait to get back into the code! The last few videos have been great to step back and look at processes from a higher level. I'm hungry for more BuberDinner.
what if you have huge data like 100000000comments in Post object. I don't think you can init a domain object with that much... looks useless to me when dealing with large chunks of data. Thoughts?
Great video! I have one question: In repository pattern if i have for example an aggregate root Post and one entity Comment that can't exist without a post, the only repository that i should create is PostRepository? Does this repository handle all operations on comments too? Does it make sense to have a method that only retrieve comment informations or have at least the postName or postId without other post's informationt, or should i return always the aggregate? CommentRepository doesn't make sense right? Thanks in advance.
When panning, try being less "instant". It's OK when you do it because you anticipate it, but for an audience it's jarring and unexpected and makes you loose your focus for a second while you readjust. It's worse when the image is highly zoomed in and the main content that you should be focused on is basically covering the full screen.
Would love to see a video covering DDD with a framework like Spring Boot! I would be curious in particular as to how you would handle the separation of domain logic from persistence/framework code.
I’m not familiar with spring boot, but the application we’re building out uses ASP.NET, and the principles we’ll use for separating logic between the layers should stay true regardless of the framework. There might be specific Java/persistence framework limitations, of course, but generally speaking, you should be able to apply what we’ll cover regardless of the framework 🙂
You can reference other aggregates by a reference to the aggregate root, not just its ID (in the storage model you can store just the other aggregate's ID). I think most examples use IDs but technically, isn't holding a memory reference to the AR safe? Because you're just holding a reference to the transaction boundary of that AR, and you can only modify it through its public interface. Right?
Can you? Yes. Is it recommended? No. Check out this article by vaughn vernon where he talks about this issue: www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_2.pdf
