3 Steps for Modeling a Complex Domain | CLEAN ARCHITECTURE & DDD From Scratch Tutorial

3 Steps for Modeling a Complex Domain | CLEAN ARCHITECTURE & DDD From Scratch Tutorial | Part 11

Рет қаралды 51,585

Күн бұрын

Пікірлер

@amantinband 2 жыл бұрын

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!

@kevlingo 2 жыл бұрын

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!!

@amantinband 2 жыл бұрын

😂😂😂

@leuras-dev Жыл бұрын

This playlist is the best content about DDD available on KZbin!!!! Thank you!

@alvin3171997 2 жыл бұрын

I’ve read “implementing domain driven design” book but always feel lost in some part, this series clear things up tremendously! Thank you sir 💯

@spottedmahn Жыл бұрын

Thanks for using dark mode for the visualizations!

@1981ilyha 2 жыл бұрын

Wow! Amazing presentation - it looks sooo simple! Thank you!!!

@amantinband 2 жыл бұрын

Happy you liked it 🙂

@maexoman 2 жыл бұрын

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?

@tenzl Жыл бұрын

it's been 3 months and no reply. Did you happen to find an answer to your question since then? I'm also wondering the same thing.

@greggles_b Жыл бұрын

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.

@felipeklafke Жыл бұрын

impressão minha ou você iniciou a modelagem justamente da forma que o livro azul nao indica?

@camcommute 10 ай бұрын

you're so good at explaining

@deivid98315 6 күн бұрын

I’m really curious about how a real big monolith performs with all these eager loaded relationships. Also what is that section? Isn’t present in the diagram, is that structure needed only for presentation data? Great videos, I’m only a bit lost in code in the middle, how this match with controllers, services, dtos, etc

@smliwhcirdeirf Жыл бұрын

I'm wondering why the menu item (in sections) isn't its own entity and is also just referenced with the id like dinner is.

@carmineos 2 жыл бұрын

Great video as usual, I'm loving this series

@kmcdo 2 жыл бұрын

Another fantastic video! Keep up the great work!

@amantinband 2 жыл бұрын

Thanks, Kyle!

@anaredbeard6052 Жыл бұрын

Hi, Amichai! Could you please explain why "Section" and "SectionItem" are not present in the "relationships" part?

@codingsavid6509 10 ай бұрын

Best video regarding this, you're a goat

@frankoppermann1877 Жыл бұрын

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?

@amanamudoaka8020 2 жыл бұрын

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.

@amantinband 2 жыл бұрын

I’ll add it to my backlog 🤙🏼

@amanamudoaka8020 2 жыл бұрын

Okay. BIG up

@davemasters 2 жыл бұрын

Another fantastic video. I think designing aggregates is really the essence of DDD.

@amantinband 2 жыл бұрын

Thanks, David! I actually think that's a misconception 🫣

@davemasters 2 жыл бұрын

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

@amantinband 2 жыл бұрын

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.

2 жыл бұрын

That's a really great content, thanks for sharing it. How would you go about documenting about side-effects happening in an aggreate (domain events)?

@amantinband 2 жыл бұрын

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.

@samirahmad248 10 ай бұрын

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?

@perelium-x 9 күн бұрын

Do you have the answers? :)

@FernandoLopez-rd8jv 6 ай бұрын

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.

@roberteru25 Жыл бұрын

Ok, what if the guest want to find all reservation, does it mean the guest will first list the dinners before getting to the reservations ?

@nareshyalagala Жыл бұрын

Whats the software you are using to create these nice design?

@dandogamer Жыл бұрын

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

@pilotboba 2 жыл бұрын

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.

@amantinband 2 жыл бұрын

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?

@srinivaspitani1326 4 ай бұрын

Buddy... I will suggest google to allow a ton of likes from each person only for your videos ;) Loved it!

@SenthilKumar-lj5cw 2 жыл бұрын

keren, sehat selalu bang, ditunggu share cara instal aplikasi macbook yang lain

@gaxkiller Жыл бұрын

Wow, dude this is so helful !

@gzoechi Жыл бұрын

Great videos. Where can I find the link to the tool you are using? I couldn't find anything in the video description.

@gzoechi Жыл бұрын

It looks like you are still using Figma but with a custom template?

@Joshiii211 2 жыл бұрын

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?

@amantinband 2 жыл бұрын

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?

@amantinband 2 жыл бұрын

Regarding visualization, I created the following figma community tool for process modeling: www.figma.com/community/file/1153317295146512523

@Joshiii211 2 жыл бұрын

@@amantinband Yes it does, thank you

@jameskelly99 2 жыл бұрын

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!