Aggregates, Entities & Value Objects | Modeling Rules of Thumb + Modeling Steps

hi everyone I'm Kai here today's video is all about Aggregates entities and value objects this is our first look into the domain layer these are the building blocks of any application that's built following domain driven design by the end of this video you should have a good understanding of what Aggregates are what entities are what value objects are and how you decide if an entity is a entity or an aggregate so if that doesn't make sense yet then don't worry by the end of this video then it should make sense I do have a quick disclaimer before we begin so even though I'm a Microsoft employee I'm not talking on behalf of Microsoft these are my personal opinions okay so throughout the examples today we're going to use this application as reference this is basically a dinner hosting platform so as a host you can create a new dinner then you can invite people to come to this dinner and they can attend if they want and guests can also just scroll the list of dinners and explore what's available and reserve a spot okay so looking at this then let's imagine how the model of the dinner behind the scenes of this UI what it actually looks like so let's imagine we have something like the following right so the name and description that we looked at are is available we also have the start and end date time then we also have here some other stuff like the location of where it is we also have the reservation which has some details like the guest count who's the guest that is reserving and some other stuff okay now that we have an example that we can talk about and imagine I want us to take a step back and I want to introduce two new domain driven design terms the first one is entity and the second one is value object so basically in the domain driven design world if you look at the Domain layer any domain object is either an entity or a value object an entity is an object that has an ID and is mutable and a value object doesn't have an ID and is immutable okay so like we said every domain object is either an entity or a value object and what's important to note is that for entities two entities are considered equal if their IDs are the same so even if the values are completely different but the idea is the same then we consider the two entities to be the same entity and for Value objects all we care about are the values so if the values are the same then they're considered equal now something that's important to note is that when we're talking about domain objects then we're talking about plain old c-sharp or Java objects where we are capturing both data and behavior so going back to our example then this entire thing is the dinner entity each one of these reservations is the reservation entity then we have here different value objects like the price right the location and we also have all the various IDs so the dinner ID the menu and host ID the reservation and guest ID and the bill ID okay now that we have a better understanding of these terms then then I want to introduce another very important concept which is an aggregate so basically when you have one or more domain objects that need to stay consistent as a whole then we call it an aggregate okay so looking at this entire thing then we have here an aggregate which is the dinner Aggregate and the dinner aggregate has inside the reservation entity and the various value objects and it's the aggregate responsibility to make sure that this object is always valid as a whole so looking at this example then when a new reservation is made then it's making sure that the total guest counts isn't more than the maximum guests or that the status is always one of the valid statuses right so you can't move for example from in progress to upcoming right you can only move to ended and so on right so it's basically making sure that this entire thing is consistent and valid as a whole okay now the entity that is the root of the aggregate is called the aggregate route so in our case the dinner isn't just an entity it's the aggregate route in this case so if we look at it from our New Perspective then we see we have the dinner aggregate where the dinner entity is the aggregate route which internally has a list of reservations that has internally some value objects and same goes for the dinner and if we generalize it for domain layers in general then the domain layer will look as following so we'll have various Aggregates which have internally zero or more entities and value objects okay so the process of modeling a domain is basically taking the different objects that you're going to have so looking at this it might be the reservation and the dinner itself and so on and thinking how you model it where everything is either a value object an entity or an and aggregate okay now this isn't a simple task and there isn't one way to do it but there are a couple of rules and guidelines that you can follow that will help you when modeling so I want us to go over them okay the first rule is that if you need to reference another aggregate route from your aggregate then you do it by referencing the ID something that's very common to do is to create a value object that contains the ID and then you simply hold that value object instead we saw it with the dinner we'll look at that example again in a few minutes the next one is a fundamental rule of the aggregate it's that the aggregate is a transactional boundary which means that changes to the aggregate are committed and rolled back as a whole so any changes you do to the aggregate you basically pull the entire aggregate from the database do whatever changes and then you write it back to the database that's why we prefer having smaller Aggregates rather than bigger Aggregates we don't want to have to read and write a lot of data if every time we want to make a change okay so this is very important and this is something to keep in mind when you're designing your Aggregates okay the last one this is a rule that is more like a soft rule you need to be pragmatic about it but basically any change to the aggregate is done via the aggregate route and this is so it's going to enforce the invariance this is similar to the rule that you want to have private Setters under objects so no one can manipulate them without you validating that the manipulation is valid okay moving on to actual practical steps of modeling your domain then like we said we want smaller Aggregates so the first step is taking each one of your entities and defining it as an aggregate then based on your invariance then you merge the different Aggregates into one aggregate so in our case that would take the reservation entity and move it inside the dinner entity okay the last step comes from the fact that if you change one Aggregate and it needs to change the values in another aggregate this is done via domain events so the way this works is you make changes on an aggregate this raises a domain event and relevant parties subscribe to these events and they make changes internally this means that the reacting aggregate will only be eventually consistent with the first aggregate so if you have two Aggregates that can't tolerate this latency then you can merge them also into a single aggregate so looking at our example then we have our two entities the reservation and the dinner we look at them as two Aggregates then because we always want the number of guests to be less than the maximum guests that are allowed then we merge the reservation aggregate into the dinner Aggregate and we end up with the following structure and lastly some good questions to ask when you're modeling okay the first one is taking two entities for example we can take the host and the dinner and ask yourself does a dinner make sense without a host okay so if the entity doesn't make any sense without the other entity then it might be a local entity and not an aggregate route the next one is will need to be looked up so are you going to search for it by ID if yes then probably it's an aggregate route and the last one is will it be referenced from other Aggregates if yes then also it's probably an aggregate route and like we said take the ID put in a value object and store it in the other aggregate so that's it for this video I really hope you enjoyed it and you have a bad understanding and something more practical that you can use when you're modeling your domain what we're going to do with the next video is we're actually going to look at the entire booper dinner domain layer and we're going to model the entire thing following the things that we talked about today okay so that's it I hope you enjoyed it and you learned something new if you enjoyed it then make sure to smash that like button and the Subscribe button and I'll see you in the next one

Channel: Amichai Mantinband

Views: 25,794

Keywords:

Id: UEtmOW8uZZY

Length: 9min 2sec (542 seconds)

Published: Wed Oct 19 2022