title: Domain Driven Design and Aggregates
body: <p>I am building a small Recipe Organiser MVC project with EntityFramework Code first and  Sql Server Compact edition as a way to learn more about DDD and the Repository pattern.</p>
  
  <p>Here are some of my domain entities, I have simplified them for this question.</p>
  
  <pre><code>public class Recipe {
  
      public int Id { get; set; }
  
      [Required]
      public string Name { get; set; }
  
      /// &lt;summary&gt;
      /// Represents a common meal type of “Breakfast, Lunch or Dinner” 
      /// or type of course “Appetisers, Soups, Salads, Fish, Poultry &amp; Game, Meat, Side dishes, Desserts, Miscellaneous", etc.
      /// (for scope I am not considering brunch or supper or any other type) 
      /// &lt;/summary&gt;
      [Required]
      public Course Course { get; set; }
  
  
      public virtual ICollection&lt;Ingredient&gt; Ingredients { get; set; }
  }
  
  public class Ingredient {
      public int Id { get; set; }
      [Required]
      public string Name { get; set; }
  }
  
  public class Course {
      public int Id { get; set; }
      [Required]
      public string Name { get; set; }
  }
  </code></pre>
  
  <p>In my opinion for the scope of this project I would say that Recipe is an Aggregate Root and Ingredient and Course are aggregates of Recipe.</p>
  
  <p>If I take this example and use MVC scaffolding to give me an example implementation of the repository pattern, I get the below interface and a EFRecipeRepository class that implements the interface and has a reference to the EF DB context.</p>
  
  <pre><code>public interface IRecipeRepository
  {
      IQueryable&lt;Recipe&gt; All { get; }
      IQueryable&lt;Recipe&gt; AllIncluding(params Expression&lt;Func&lt;Recipe, object&gt;&gt;[] includeProperties);
      Recipe Find(int id);
      void InsertOrUpdate(Recipe recipe);
      void Delete(int id);
      void Save();
  }
  </code></pre>
  
  <p>Following this guidance: </p>
  
  <blockquote>
    <p>In the context of the repository pattern, aggregate roots are the only
    objects your client code loads from the repository.</p>
    
    <p>The repository encapsulates access to child objects - from a caller's
    perspective it automatically loads them, either at the same time the
    root is loaded or when they're actually needed (as with lazy loading).</p>
  </blockquote>
  
  <p>I would expect to add more to this interface, in order to obtain an Ingredient or Course via a Recipe.</p>
  
  <p>The problem I have is that I want to add some features to my Views that involve just the Ingredients or Course, for example: A navigation of all the different types of Courses (not just the ones related to Recipes) and an auto-complete list for ingredients.</p>
  
  <p>In the scope of my project, Ingredients don't exist outside of a Recipe so it seems viable that it should be an aggregate of Recipe. Course however seems like it should be an Aggregate root itself, because of how it exists on its own?</p>
  
  <p>I am struggling to get a vision of how this all should work, if I wanted to obtain a list of every Ingredient would that mean that I would first have to use the Recipe Repository to load up all the Recipes in order to find all the Ingredients?</p>
  
  <p>Course has a similar problem except that it is used as a way to categories Recipes and so can exist outside of that boundary too.</p>
  
  <p>Is there some concept I am missing? perhaps a way to create a Service that is used for such Presentation layer requirements? Does anyone have any opinion on how this should be done? or any better suggestions? Thanks</p>
  
  <p>On a side note, this is a small project and DDD might not be the best approach, but I do find the repository pattern very useful for persistence ignorance in my Domain model.</p>
  
  <p>Thanks</p>