@bartoszperek5213
Great video. I have one question actually - how you co-relate ProjectMember with Employee class? Maybe I'm missing something but it seems that ProjectMember is a Employee in a certain role. As the rule of thumb is to keep aggregates small - a reasonable decision is to not load all employees into aggregate. You've introduced concept of ProjectMember - do you load all project members into aggregate? What is hundreds of people can join project? Should there join logic be extracted into Domain Service and there check if there are free spots and if Employee is not a member already?
@anatum0205
Thank for your video. It is very usefull. Let say you have an application with authentication, and users can have different roles. Who is responsible for a method into the aggregate that can have different behaviour according to the role ? And how to get the role of the current user into the aggregate ?
@zutafe
Nice. So, an aggregate should reference to other aggregate by ID, is that right? And, do we need to add navigation properties for fetching data? Wait for your next video of this topic.
@MongiHAJHAMMAMI
Thanks for the video, so clear and instructive. But i have a some complicate situation where i cannot apply the principle of state changing only through aggregate root. Well, suppose i have an entity defined as a shared "business" kernel (ContactInfo, Blob, ...), and witch i use as member of aggregate roots for multiple domains in multiple Microservices. This entity is defined in a separate class library projet (referenced into my domain project). Im forced to define setters inside this shared entity as public. Any alternative ? 🤨Thx
@usmanrahat2913