CODEWITHSUNDEEP
domain-driven-design
user4095212
user4095212

Reputation:

DDD, entities, model boundaries

Let's take this simple example. We have two modules. One module is about some questions where we have entity Question. This entity require entity from other module, an User.

When I need to list all questions (with their authors), my QuestionRepository needs to fetch users as well. Questions:

Or something else?

EDIT: please don't write about ORM. That is a tool. I believe this question is about what is actually shared between the modules.

Upvotes: 0

Views: 180

Answers (4)

Eben Roux
Eben Roux

Reputation: 13256

If indeed Question and User are in two different BCs then you may find that User in the Question BC is actually something else, like QuestionOwner. I am, of course, making up this term for illustrative purposes. :)

An AR should never contain an instance of another AR so irrespective of whether they are in the same BC or not the contained AR (User in this case) should be represented either by an Id or, more appropriately, a VO. Let's go with a QuestionOwner that would contain the UserId and UserName that is stored in your Question.

In this way the Question BC consumes some of the User BC data and represents the data in a form that has meaning in the Question BC. Remember that since VOs are immutable you would not administer any QuestionOwner data in the Question BC and even if the corresponding User data is changed in the User BC you have the added benefit of representing the User data as it was when the question was, say, created. These design decisions are something that you will make depending on your use case. You may also opt to update the Question 'owners' using some eventing framework (service bus) when the user data changes.

Upvotes: 0

Roger Johansson
Roger Johansson

Reputation: 23224

It depends on what responsibility you want your repositories to have, there are two approaches:

  1. Your repository is responsible for fetching complete and isolated aggregate roots. with no navigational properties to other aggregates.

  2. Your repository is more like a Query container which contains the queries that your domain needs.

Nr #1 is more isolated and works very well if you don't have an O/R Mapper, you can simply construct your aggregates and return a dead list of aggregates.

Nr #2 is a more pragmatic approach if you do use an O/R Mapper. This is because 1) O/R mappers can deal with navigational properties and entire graphs of objects. 2) Some mappers, e.g. Entity Framework will attach entire graphs of new objects when you "Add" to the repository. e.g. say you create an Order, an OrderDetail and a Product, together and you call .Add(order) or .Save(order), EF will attach all three entities. that is, the Product will also be saved if the detail points to it.

So, if you use an O/R mapper, I'd go for approach #2..

And also do note, this as very Little to do with DDD, DDD is about semantics and the model, not about how your infrastructure is designed..

Upvotes: 1

mss
mss

Reputation: 64

If you are using EF5 and Linq you can write linq query to fetch both

Upvotes: 0

mss
mss

Reputation: 64

If Questions entity has a foreign key UserID field & relationship set to Users entity, it is possible to fetch questions along with users.

Upvotes: 0

Related Questions