Reputation: 8580
I have the following data structure:
class Post
{
public string Title { get; set;}
public Category Category { get; set;}
}
Bearing in mind a post always belongs to one and only one category is my reasoning correct?
Category
is the aggregate root (since a post cannot exist without it)CategoryRepository
(with methods such as GetCategory
and GetPost
) but not a PostRepository
(because Post
is not an aggregate root)Upvotes: 2
Views: 776
Reputation: 29956
How do you want to reference instances of Post
? Is Post.Title
a unique identifier for a Post
? If so, then Post
is a valid aggregate root and you should create a PostRepository
which retrieves an instance of Post
given it's Title
.
Take the example of a car. A car must have a colour, but stating that the colour is the aggregate root just because a car cannot exist without one is the wrong thing to do. I want to reference a car independently given it's license plate number (which is independent of it's colour). The fact that it must have a colour is simply a feature of my car domain model which states that I cannot construct a car instance without supplying the colour.
Upvotes: 5
Reputation: 33128
I often cite this resource when it comes to aggregate root design considerations RavenDB - StackOverflow style voting with Live Projections. This addresses some of your key thought process and should show you why Category would be a VERY POOR aggregate root.
Upvotes: 1