Glad you enjoy it!

I'm glad you found it useful.

An aggregate should never contain another aggregate as navigation property. That would ruin the consistency boundary.

@@Codewrinkles as your demo, how about treating ProjectMember as a value object instead of an entity?

I think that would definitely be a possibility. My idea was that project members should actually have a thread of continuity as roles might change and we want to keep track of different state changes. And that's the scenario for entities. But, for instance, the Customer in the demo is a value object. Aggregates can and should contain both.

@@zutafe That is not a bad idea. Since members are linked to projects, and are not entities on their own.

Thank you very much for your comment. I'm not really sure how your question fits into the DDD perspective, as this is a challenge for all other types of architecture. To put it into a DDD perspective and based on the experience I had so far in this field I'd say that if you need to load a lot objects, then there's probably something wrong with the overall architecture and design of the application. If I would have a project with 1000+ project members, then I'd probably need to re-model everything. DDD helps you a lot in this regard, starting from signaling out bounded contexts, then keeping aggregates simple (remember the video, an aggregate should only contain objects that are bound together by some very specific business requirements). Adhering to these principles usually leads to pretty small consistency boundaries in which things should be manageable.

@@Codewrinkles Thanks :)

Well, that's a good question and will be answered in a video. There's also the concept of domain events and side effects and how to use domain events to handle side effects.

DDD is for commands but queries. Use something like Dapper for your queries.

@@AndersBaumann what?

@@donnyroufs551 Don't use entities for queries. You don't need all the business rules. Have a look at CQRS.

I think that's a problem no matter if you use DDD or not. And the answer to it is sime: you don't load all data at the same time. You introduce paging or fltering based on other data poits that are important for your domain. If you take a look at literally all planet scale apps out there, you'll see that all of them use this approach

The answer to this is not simple because it really depends on each application requirements. What I have found out in refactoring a lot of production apps towards DDD is that usually the idea of roles is actually not a business rule. That's an application rule and therefore it should be handled at the application level. There are however also scenarios where type of roles would play a big part of the business rules. In these scenario I often found out that the roles that are really needed for the business rules don't usually correspond to the roles we define in our auth systems. For instance, in auth systems we might have a role Admin. In DDD we'd probably have an aggregate called "Administrator". Let me give you a concrete example. I was working on an application that handled approvals for payments in a company. There were different roles involved there. For instance, only a finance user could give the final approval. In the app, everything was a "User". So everything was cumbersome. Talking to the customer while trying to get the ubiquitous language they used, I found out that they were referring to the users in different terms: lawyer, auditor and so on. And it turned on that the auditor was the one approving requests. Therefore, Auditor became part of my domain. Then we had a domain service (see latest video:)) for payment approvals where we provided a paymentRequest and an auditor, and the service enforced all cross-aggregate business rules. The major challenge with DDD is that people try to "do DDD" using a very old mindset. On of these mindsets is that we have a "User" and then we have a bunch of roles. However, if you listen to the ubiquitous language, you'll soon find out that there no such thing as "user". Depending on the domain of the app you might have: ContentCreator, ContentApprover, Accountant, FactoryWorker, Developer and so on. If you're doing DDD for good, you'll probably never have a class "User". Hope this helps.

Yes, and I have a video dedicated to domain events.

I think there is a common misconception here. Value object can encapsulate their own behavior (methods). Think about the DateTime struct. it has a lot of behavior that's strictly related to a date and time. However, when it comes to an aggregate, the root is the one who should know when certain behavior from the value object should be used or not. I'm not sure I fully understand the challenge.

@@Codewrinkles Thx a lot, effectively there was a misconception. Its all about ValueObject to encapsulate own behavior. That solve the problem, thx