5

I am new to DDD world, I want to apply it to our DDD application with ADO.NET. There are entities, aggregate root, value object in DDD. I have two entities, such as a blog post which maybe can belong to several categories. Actually I think the blog post and the category all should be aggregate root. The blog post and the category all have a repository, PostRepository and CategoryRepository, but now i am confused about how to implement the persistence of the 1:many relationship between post and category entities.

In DAO pattern, there is an DAO corresponding to a table, we can persist the relationship in the DAO class. But in DDD, there are concept of Unit of work, it can ensure the aggregate root work correctly, like this, there should be some repositories about the entities of the aggregate root. but for the relationship I don't think it should have a repository, it is not a entity here.

Is there a best practice to solve these scenarios? or should I add two procedure(add post, add category) and call them when I save the post?

Ron Smith
  • 197
  • 3
  • 17
  • Possible duplicate of [What is the difference between DAO and Repository patterns?](http://stackoverflow.com/questions/8550124/what-is-the-difference-between-dao-and-repository-patterns) – guillaume31 Dec 20 '16 at 09:41

1 Answers1

5

You should have a single repository per aggregate root.

If you think about a structure of objects, like your Posts, then the aggregate would be the Post with a Category. The Post would be the aggregate root. If an entity is just on it's own, you could think of it as an aggregate root in itself (just an aggregate of one object). So your rules for creating repositories, is one for each aggregate root (or single entities of one object).

If you make Category part of the Post aggregate, then you must never access or modify Categories directly. If a Category needs changing, it is done through the Post object. If this doesn't sound like your domain model and you're thinking "but I want to manage my Categories separately", then there's a good chance that Category doesn't belong to the Post aggregate. If not, you probably want to model the Category as it's own entity and reference it by id (not object reference) from the Post entity.

How you then go on to model Categories depends on your own Domain. This happens a lot with DDD. But it's all good. It just means that the way you model your domain is 100% dependent on how your particular domain works.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
  • Thanks Adrian, here I will manage the category separately. I use a table to store the relationship which categories the post belong to, in DDD with entity framework it will be done automatically, if without ORM, is there are elegant pattern to save the Post and its categories? – Ron Smith Dec 20 '16 at 09:53
  • You could just use something like ADO.NET, firstly removing the existing links and then reinserting them. – Adrian Thompson Phillips Dec 20 '16 at 10:24