A question about aggregates in DDD
I am watching a DDD course and the author created the following classes
18 Replies
Here what's the value of having an
Id
that just Wraps the guid ? why not use a GUID directly as simple as this directly in the Resource
class
Why all this "boilerplate" ? What's the purpose to inherit from an AggregateRoot
```
I am lost 😅You generally use strongly typed IDs to prevent confusion later on.
Imagine a method in which a user edits a comment under some post. That needs the id of the user, the id of the post he is editing and the id of the comment and of course the new content.
Now the signature would be Guid, Guid, Guid, string. It is very easy to make a mistake here. Like passing the userId as a commentId.
If you use strongly typed IDs, your signature becomes. UserId, PostId, CommentId, string. Now you cannot mess this up, because the compiler will stop you.
also because DDD is tons of boilerplate
but if the user is an aggrgate, and the post is an aggregate and the comment is an aggregate, the signature would be AggregateId, AggregateId, AggregateId, string right ?
No
because all of three will inherit from AggregateRoot
Generally you wouldn't do that. But in this example yes.
But those three wouldn't all be aggregateRoots
is there a reason you're trying to use/learn DDD?
it's generally a mess that you shouldn't bother with unless forced
DDD is a lot of boilerplate that may pay off in the end, but for any smaller projects it's probably not worth sticking to it.
I am forced to for an interview yes, unfortunately -_-
but I am untrested to learn about simpler stuff as well
any suggestions on materials about architecture ad design but that are simpler ?
$vsa is generally recommended over DDD/CA here
I would use a generic Interface for the AggregateRoot. Like AggregateRoot<TId>
Architecture is very hard to learn, without trying out a bunch of stuff and experiencing the advantages and disadvantages of them all.
@Joschi why making it generic ? any advantages ?
I mean, if you don't want to do DDD, not for nothing here, don't interview for a DDD position.
The advantage is, that you can use a different strongly typed ID for each AggregateRoot instead of having a single typed ID be used multiple times, which kind of defeats the purpose of strongly typed IDs imo.
that's in theory, in practice I need to eat. Contrary to USA, DDD is still a huge thing in Europe, unfortunatel
@Joschi thanks !
Is it?
There might also be some conflating of DDD and event sourcing going on here. But I imagine DDD when applied often goes into the cqrs and/or event sourcing just because of the available material