views:

128

answers:

2

Hi,

I have these two structures in my domain: Exercise (with subjects, solution, difficulty ext.) and Subject which has a name and a father subject. Subject is defined by its attributes so in that sense it's a value object, However even if my current data store has nothing associated with a particular subject, that subject existence still might be relevant for the domain, so it can exist unrelated to anything- so is it an entity ?

Another question, say I want all existing subjects that have a particular name is it advisable to have a SubjectRepository (should only aggregate roots have associated repositories)?

A: 

If you need to change the subject and you have the need to track it, it should be an entity. In what sense is the existence of the subject in the domain relevant? If you can't fit the subject into the domain in a sensible way, it might be a service you need.

To your second question; yes, it's wise to only have repositories for aggregate roots.

Fossmo
Thank you for your answer.How should i encapsulate a query to fetch all existing subjects which have a particular name?
gkdm
It depends on how you are going to use the subjects in your domain.
Fossmo
1. fetch associated entities of varius kinds.2. provide auto complete functionality (like stackoverflow tags).3. eager load an exercise associated subjects.
gkdm
+1  A: 

I've seen a similar DDD case regarding an Address class.

Domain-wise, the properties were the interesting part, not the id.

However in order to re-use and edit them, they needed to be «entities» with no business id/key, only a primary id/key.

In order to support smooth management in the GUI, Address was made an «aggregate roots» with a «repository».

Your case sounds similar.

Martin R-L