Domain model relationships confusion

.NET
1

Feels like a bit of a stupid question considering it’s perhaps the simplest part of a domain model/ddd approach and given the amount of reading I’ve done on entity equality/identity, repository implementations, nhibernate, session/uow, IoC and all the other fads/techs/patterns. Think I might just be confusing myself here but we’ll see.

How do I handle the relationship/references in the following domain model? A theme park has one or more sectors within it and each sector has one or more attractions, the attractions therefore belong to both the location and the theme park (e.g. ‘Splash Mountain’ is a ride at ‘Magic Kingdom’ within the ‘Frontierland’ sector of the park). How do I model that correctly?

class ThemePark : Entity
{
   ...
   public virtual IEnumerable<Sector> Sectors { get; protected set; } 
   ...
}

class Sector : Entity
{
   ...
   public virtual ThemePark Park { get; set; }
   public virtual IEnumerable<Attraction> Attractions { get; protected set; } 
   ...
}

For the attraction do I reference the park and sector it belongs to or just the sector? Do I maintain a list of the attractions from within the Park object? Do I even need those ‘up’ references to the parent objects? Obviously I’d be using an IParkRepository implementation but that means if I just want to list all attractions, at say all Disney parks, I have to cascade through the ParkRepository selecting all the parks, all their sectors and then all the attractions belonging to each sector. Do I use a seperate IAttractionRepository? The actual parks are the root of the aggregate though so another repository contradicts my understanding of DDD. Should I go read again or am I just over complicating things and having a doh moment?

2

First of all, IoC is not a fad. It makes testing and loose coupling much easier. :slight_smile:

As for your design issue, you’re kind of getting into a recursive querying thing. If you get too wrapped up in how the object graph, you’ll overlook some obvious better way. For example, querying with SQL, LINQ or NHibernate would yield the collection of objects you want, and you wouldn’t have to do anything beyond what you already have in terms of the shape of your classes.

I don’t remember off hand what we’ve done with enums and NHibernate, but I think we just used the integer values. Best way to find out is to experiment.

3

Your model should reflect your needs, not your database layout. Create the model according to what it needs to do, don’t create lots of entities just because you have lots of tables with relations between them.

Use your repositories to hide all that involves database (access, layout etc) and create the business objects to respond to specific needs.

I’m a big fan of CQS (Command Query Separation) and in this case it seems it’s a query. If you just want to get a list of attractions, create a AttractionInfo DTO which holds all the required fields and ask the repository for a IEnumerable<AttractionInfo> .

You don’t need entities for that purpose and it’s cumbersome to create one Entity to fit them all (CRUD and queries). Create according to specific needs or else YAGNI.

4

Also, while I’m here.

Does anyone know how NHibernate handles persisting enums? Does it store the text value or will it assign each enum value an integer? Do I have to set any specific mapping config in the mapping/fnh map?