Mastering DDD Aggregate Modeling With THESE 3 Steps

[@tantruongthe-z7o]

So, if an entity (that is mapping to a table) can be an aggregate by adding bussiness logic inside its class (rich model), then perform CRUD with that class to persist into DB ? The AggregateRoot, because of it empty, is only use for marking that some classes is an aggregate root ? When you say fetch aggregate with related entities, you changed the repository codes, why ? We still can use Include() method for the same purpose. I have a small design, see below: A class named User (Id, Name, List SkillList, List ProdList ), Skill class (Id, SkillName), Product (Id, ProdName). When i create an user, it will also add all products belong to current user, i am tending to create an aggregate named UserCreateAggregate that only has 2 required props (User user // root, List ProdList) with a void CreateMethod() { user = new(); user.prodList = Prodlist; }. I am stucking right here, i don't know how to persist to DB, i have 2 ways, feel free to express your opinion: 1. Pass UserRepo to Aggregate then saveChanges(), this way worked but it looks stupid :) 2. Return current user (use prop that is declared earlier) to service class then userRepo saves it to DB. (this seems more appropriate). Additional info, i am using EF Core with UOW and repository (For each entity).

[@jakoblindblad191]

This is a great series thank you very much.

[@Codewrinkles]

Glad you enjoy it!

[@rizadwiandhika9253]

Hi!, i found your content is really useful. I want to know though on how to deal with this case: In the Project aggregate root, what if the project members could be a very large members? let's say it could be 10,000 or even 100,000 members in a project. Do we really load the whole project members in the aggregate root? or do we use something like pagination? i feel like we need to do the pagination solution, but i don't know how to implement that in DDD world. meanwhile if we load like 100.000 project members, there could be a memory issue though.

[@pianoman1973]

Thanks for the tutorial ! I'm new to DDD and the first thing that pops to me is what should we do in case project has a lot of members. It doesn't seem practical to load them each time into memory while manipulating the project. How should we tackle this ?

[@Codewrinkles]

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.

[@pianoman1973]

@@Codewrinkles Thanks :)

[@saber.tabatabaee]

thank you very much. very very very good cbt here. congress. i enjoy it very much. is there any github repo there for codes that you write?

[@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.

[@Codewrinkles]

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

[@zutafe]

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

[@Codewrinkles]

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.

[@marna_li]

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

[@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?

[@adrielairaldo]

Spectacular material to move ideas with a spectacular use case! In fact, I came with a problem in mind, and I solved several others that I had pending. Just to add, there is a little tip (which I think is in Eric's book) and that is: if I delete an Aggregate Root, the elements contained by the Aggregate Root should also be deleted. This helps us discover "whole and its parts" relationships. Through this principle we can ask ourselves: does it make sense to have this entity decoupled from its "root"? Thank you! I enjoyed it a lot.

[@Codewrinkles]

I'm glad you found it useful.

[@donnyroufs551]

How would I do a query that gives me all the projects a employee(user?) has been in? Do we simply add the relation just like in rule 3 to the ProjectMember?

[@AndersBaumann]

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

[@donnyroufs551]

@@AndersBaumann what?

[@AndersBaumann]

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

[@daredev-h1h]

Thanks for this! It's very informative. I'm just wondering how you would handle it if the project member changes his/her FullName. Wouldn't you go back to the original problem?

[@Codewrinkles]

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.

[@alpsavasdev]

Thanks for the video! How do we ensure data consistency between the ProjectMember and Employee tables? For example, when an Employee quits, how does that is reflected in the ProjectMember entity? I guess it has something to do with the Domain Events...

[@Codewrinkles]

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

[@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 ?

[@Codewrinkles]

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.

[@botyironcastle]

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 chuncks of data. Thoughts?

[@Codewrinkles]

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

[@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

[@Codewrinkles]

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.

[@MongiHAJHAMMAMI]

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