To recap: 1. Identify Entities and treat each entity as an aggregate root 2. Identify relationships between the entities 3. Merge aggregates if there are constraints Possible constraints: 1. Enforcing Invariants 2. Eventual consistency cannot be tolerated Good indicators that an entity should be an aggregate root: 1. It is referenced by other aggregates 2. It will be looked up by Id Curious to hear what you think!
I'm obsessed with you...but not in a creepy way 😁 You have a way of simplifying things without dumbing them down. That's a tough thing to do. I am waiting with baited breath for more in this series. PURE GOLD!!
This is one of the best videos I’ve found explaining how to model the domain. I’m a complete beginner in DDD so this step by step guide helps a lot! Thank you so much! I still have one question left though. I understand your decision to make the reservation be part of the dinner. Doesn’t it become a performance bottleneck at some point? How would you handle something like a concert where you wouldn’t like to sell more tickets than you have. So the tickets would be part of the Concert aggregate but wouldn’t it be unreasonable to load like 50k rows just to check not that it won’t be overbooked after adding another purchase? Would you use lazy loading and a counter in this scenario?
You’d have to go with an eventually consistent approach: - Create a Reservation in an REQUESTED state (pick whatever name best fits your domain). Publish a ReservationRequested domain event. - Whenever ReservationRequested, invoke domain logic of the Dinner aggregate (in a separate unit of work), I.e. HandleReservation. - The Dinner aggregate keeps a list of accepted reservation id’s so it can determine whether the capacity limit has been reached. Publish a domain event DinnerReservationHandled with the result. (You have a choice here whether to have separate events for accepted/rejected, or whether to model them as one event. Either way you need the event to update the Reservation to its final state. You can likely find better domain language to use than “Handle/Handled”) - Whenever DinnerReservationHandled, invoke the Reservation aggregate to update its state to ACCEPTED or REJECTED. To implement this workflow you can use an event-driven or orchestrated workflow. I’d likely avoided events and go with the latter since you’re always likely to have edge cases, such as what happens if the guest cancels their reservation after the Dinner aggregate accepts it but before the Reservation is updated. Or if the host changes the venues capacity… These are valid workflows in themselves and may require the use of the Saga pattern to undo the action on the Dinner and perhaps invoke subworkflows, like cancelling someone’s reservation. I just think integration events can get super complicated and you can lose track of the high level business processes in a web of events. Take a look at Temporal.IO or Camunda for workflow orchestrators.
@@amantinband really? how so? I've always felt like people tend to focus on "layers" and implementing repositories/factories etc rather than thinking about defining transaction boundaries
I agree that aggregates are an essential part of DDD. I'm referring to the misconception that "DDD" == "tactical patterns," not considering many other practices and strategic design patterns.
I have a question to the relashionships. Example with Menu and Dinner: In the Menu, you are referencing a collection of DinnerIds. In the Dinner, you are referencing the MenuId. What, if you add a Dinner and forget to add the DinnerId to the referenced Menu? Where is the correct relationship stored? In the DinnerId-Collection in the Menu or in the MenuId-Field in the Dinner? I think, a clean way is to store the parent menuId in the Dinner. The collection in the Menu should not be used. If you want to get all Dinners related to a Menu, you can filter the Dinner-Aggregates by MenuId. The single point of truth. If you also can ask the Menu-Aggregate for the result, you can possibly get another result. How should the relashionships be handled in a clean and correct way?
Thanks a lots, you are opening our eyes. Please do something on ubiquitous language (UL). How we can create one and use it to tie analysis model to code model. It would be a big boost for me. Shis you just opened me eyes. Thanks a lot.
So, one thing I have sort of understood from my early diving into DDD is that an Entity is meaningless without context. So, customer means something completely different in the Sales context vs the Finance context. So, maybe I'm confused when you say the dinner will be a value object in some other aggregate, but then on your model diagram, you list it is DinnerId... which sounds like a reference. I thought a value object had no idea, it was differentiated by it's values, not by it's id. Perhaps when you get into code this will make more sense, but it's not clicking for me right now.
Hey Bob, missed your insights in the last few videos! 🙂 Sort of. I would say the following: 1. Terms (anything from Aggregates/Entities/enum values to general terminology) have meaning only within a bounded context, so 2 terms can have different meanings depending on the context. 2. If aggregates need to reference each other, they do it by id. 3. Entities are identified by their id. 4. Value Objects are identified by their value. 5. An Aggregates id must be unique within the bounded context. 6. A local Entity's id must be unique only within its parent aggregate. In the video, we have a single Bounded Context. This means that each term has a single meaning within our Domain layer. When our various Aggregates reference one another, they do so by id. If we have the following (notice the id of Aggregate 2 is a number, not a string): Aggregate 1: { "id": "1" } Aggregate 2: { "id": 2 } If we want to reference 2 from 1, we can either create a property to contain it: Aggregate 1: { "id": "1", "otherAggregate": "2" } Or, create a value object that contains the id. And store that instead. For example: class OtherAggregateId { public int Value { get; set; } // Aggregate 2's id value object definition Aggregate 1: { "id": "1", "otherAggregate": { "value": 2 } } This abstraction layer allows us to update Aggregate 2's id type/structure without updating all referencing entities. It also allows us to encapsulate id generation logic for example: $"Reservation_{GuestId}_{DinnerId}" Does that make sense?
Maybe I need to go back and watch some videos that describe entities and aggregates because I was getting a lil lost here. But this just looks like SQL modelling to me...
question. Is having the average rating as a property of your menu really needed? What invariant/behavior does it satisfy? It to me looks more like a read model property. Not sure If I am making sense here.
Thanks, Arley. The aggregate markdown file is a natural place to put all aggregate-related details. We'll cover Domain Layer folder structure in a video next week, but generally, the approach I use nowadays is: > Domain > Aggregate Type (for example 'Dinner') > Entities > Enums > Events > ValueObjects So if the Domain Event documentation only lists the domain events, it might be simpler to look under the Aggregate's Events folder.
Hey, I wanna thank you for this series, it helped me alot. But forgive me for my long question because I am really confused: 🔷is the Host id and Guest id are really needed in the User aggregate ?? 🔷how should I implement the authorization and authentication if so, should i add the password, email... properties to the user aggregate??.. 🔷Since the Host and the Guest have different bussiness rules, how should i implement this? should it be implemented in the Domain services (the Application layer) or in the Domain layer where i can add some rules to the aggregate itself? 🔷can one aggregate inherit from another one? like the Host inherting from the user aggregate?
Super informative video, thanks for making this! What tool are you using or what tools can you recommend to visualize the modeling process? I don't really understand the first approach you are describing at 13:36. If we create another entity under guest, wouldn't that be a mirroring of the reservation entity and introduce eventual consistency problems? Or did i understand your approach wrong?
Thanks, Lycosh! The first approach would be creating a new entity/value object, for example "UpcomingReservation", that would contain the relevant properties. Then, reserving a dinner would raise the "DinnerReserved" domain event. This event would trigger a handler that would result in the Guest entity having a new UpcomingReservation object. Like you said, the Guest entity will be eventually consistent. Does that make sense?
Perfect timing, I am working with an aggregate currently that has got too big and was wondering how to break it down…I knew the theory, but had struggled with implementation. You have shown me exactly how to go about it so I can easily implement! Thanks a heap!
