What makes an Aggregate (DDD)? Hint: it's NOT hierarchy & relationships

preview_player
Показать описание
How do you design an aggregate in domain-driven design? An aggregate in a cluster of related objects and used to manage the complexity of business rules and data consistency. Designing aggregates often incorrectly because of the focus on the relationship between entities.

🔗 EventStoreDB

💥 Join this channel to get access to a private Discord Server and any source code in my videos.

🔥 Join via Patreon

✔️ Join via YouTube

0:00 Relationships
2:05 Aggregate
5:12 Invariants
6:00 CQRS

#domaindrivendesign #softwaredesign #softwarearchitecture
Рекомендации по теме
Комментарии
Автор

This is great, I definitely dug myself into that hole when I started off and wished that I had this as a resource back then.

dropbeardan
Автор

Thanks, I've been wondering about this for years, finally you made it clear to me why an aggregate should only be used for state change and not for queries.

wertrager
Автор

Great introductory video to this aspect of DDD. Primarily because it's thought provoking and this is an important topic that needs thoughts provoked!😀

This is the kind of video that fosters the sharing of wisdom rather than merely knowledge. And for that you deserve a lot of credit. This sort of material will be invaluable to so many careers and will really raise the bar for so many once they grasp what you're sharing with them.

Having said that, we're just scratching the surface here and I think this video needs (and deserves!) a follow-up of similar length using the same example but to a slightly greater depth (yet still introductory... linking on to other videos you've made related to this). Or episodes 2 (commands) and 3 (queries) of a three-parter with similar linking into related material. I think would help a lot of people start to get over this significant mental hurdle and start to get to grips with seeing the "Big Picture" of this important aspect of DDD.

I know you've covered all of this elsewhere in some form, but perhaps not coming at it from quite this angle of hierarchy & relationships. Or at least not with quite the same sharp focus on this topic from this perspective that you've achieved here. 

Great video, though - as usual. 🙂 And many thanks for posting this. Good work, fella!

appstratum
Автор

Another piece of gold, thanks a lot for this great content, Derek! I got one question though (not directly related to your video):
Let's say you have two services (Service A and Service B). Both services are in their corresponding boundaries. Both services are aware of the same aggregate (e.g. Order) but with different attributes/properties. However, both services need the same property from the client to perform some type of calculation. Let's call that property "P". Each service needs the property P to calculate other values that are used for validation, let's call the calculated value C. So, the property P is just used to calculate C. Now, what if both services (Service A and Service B) have to perform the exact same calculation to resolve the property P to the calculated value C?
Is it better to have a dedicated service (e, g, Service C) that calculates the value of the property C for each aggregate, and publishes that via an event, or should the calculation logic be "duplicated" among both services in the first place (Service A and Service B)?

MrDomenic
Автор

thank you for the content.
A classic aggregate example: Order in an e-commerce system, which includes basket, basket items with its prices and so on. But I didn't a comprehensive example project written in golang. Most of all contains basic structure

ismailbayram_ce
Автор

Thanks for the video! Top notch content, as usual.

romanlunin
Автор

Sup Derek, like i mentioned in the last video, you might want to invest in a DSLR because the video looks blurry :)

Good content!

ZadakLeader
Автор

This is really a more resanble way to design the software.

quilhon
Автор

I agree on the idea of the video but publishing an event to make a change in another aggregate is adding complexity instead of removing it. This kind of hidden side effect will make the codebase difficult to understand, test and maintain. To me it is a misunderstanding of what domain events are for: To notify the outside world (outside the bounded context) of state changes.

AndersBaumann
Автор

I don't get how you keep consistency between the location an vending machine, how do you enforce that each location can only have one vending machine with this method? Or for example, if I already have an registered vending machine that I want to place it in a location, how do I enforce that invariant across boundaries?

thomasjardanedeoliveirabou
Автор

what if you have huge data like 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?

botyironcastle
Автор

Thanks for the video! Good stuff as always. Did you by any chance read the "Kill The Aggregate" blog series by Sara Pellegrini? A video with your take on that would be awesome!

jqtcojt
Автор

Lets say i am trying to model the problem of doing some business operations on historical stock data, so a stock is basically a symbol (for example AMZN), and a time series that represents the data of that stock. Often we want to query and do operations on the stock data based on symbols, so ultimately my question is, should symbol also be an aggregate root, alongside with stock? If not, should i still have two separate repositories? If so, should I create a repository that encapsulates both of them? How would you go about handling this situation of nested aggregate?

roeiohayon
Автор

I guess in the end an Aggregate is just simplifying the operations between simpler concepts like a route or a vending machine? That's how I see it

ZadakLeader
Автор

ok noob question time, i'm trying to watch this and other of your videos to see if i can put together all the pieces. It seems to me that Aggregates are basically modelling business processes.
If i have an ecommerce and i give the user a settings page to add products definitions to the catalog, aggregates are not really needed. Sure there is a "dummy" business rule that the price cannot be below zero, but it's a simple validation on a crud operation.
When instead users place an order, a whole process is spawned and we need to make sure it will go trough respecting the invariances, aka the real business rules, in which case an order places cannot be have a total below zero but it's a different story then doing crud validation like before, we have to check the quantities etc etc.

But then i see the Amichai example you reviewed in another video and i fail to see where aggregates can be usefull, where the business processes are. The user make a reservation for a dinner and that's it? now the next user might not be able to make the same reservation and he will need to choose another date, but it's not like we have to send notifications to the kitchen or other deparments to get ready for the dinner. Sorry i'm might getting confused here.

ghevisartor
Автор

good example how designing bounded context went wrong.

slobodanmikaric
Автор

Everyone is doing DDD Aggregates the wrong way!!!

... it's actually impressive!

BraBo
Автор

How do aggregates work in a scenario where you have one entity which has many different lists of other sub entities and these may also have lists. So in highly nested entities. Could you set the aggregatr root on different entities that may be nested but need different domain events or something like that?

flobuilds
Автор

A beginners video on how to get into API design would be neat. ^.^

emonymph
Автор

What if vencing machine can't exists without the Route object.I mean between Route and Vencineg is a composition relation.?Won't be forced to include int he same aggregate(object) all the objects cluester?Thank you!

thedacian