DDD confused with Repository Pattern and Reports

Question

I am new to DDD and the Repository pattern, so my understanding of it might be totally wrong. But I am trying to learn it. Having said that I need to create an application, which shows the zones of a store. I create a ZoneRepository for that purpose, which works so far with my few methods. Now in that application I also need to show the distinct styles for that store. The list of styles will be used to drag them into the individual zones. Now my question is where does the styles class belong to, since its kind of a mini-report. Does that "StyleReport" belong into the repository? Does it belong somewhere else? How you know where it belongs to? Please help me to understand.

Answer 1

Repositories only act on Aggregate Roots. Aggregates are a boundary around one or more objects that are treated as a unit. By that I mean, when you operate on that data (inserting, updating, deleting, etc.), all of the objects within that boundary are affected accordingly. Every aggregate has a root. This root is what is referenced externally by other parts of the software. I guess one way to describe it is "something that doesn't rely on something else".

It's a little challenging to derive the proper definition of your domain from a description of your existing models. Furthermore, the design should be based on the business model and needs, not how your UI or application works. So, you should model it on the general problem you are solving, not on how you think you'd like to solve it.

It sounds like you have an entity Store. A Store can be divided up into one or more Zones. Each Zone then has one or more StyleReports. It sounds to me like the Zones are dependent on a Store, so the Store is the aggregate root. Now, perhaps these StyleReport entities are a global set of objects that you offer in your problem domain (meaning you define the StyleReports separately, application-wide, and refer to them in your Zones). In that case, perhaps StyleReport is also an aggregate root.

Here are some example models (C#, not sure what language you're using). However, don't take this as the absolute word. If I don't know the specifics about your domain, I can't very well model it.

public class Store 
{
   public Int32 ID { get; }
   public String Name { get; set; }
   public IList<Zone> Zones { get; private set; }

   public Store()
   {
      Zones = new List<Zone>();
   }

   public void AddZone(Zone zone) 
   {
      Zones.Add(zone);
   } 
}

public class Zone
{
   public Int32 ID { get; }
   public String Name { get; set; }
   public IList<StyleReport> Styles { get; private set; }

   public Zone()
   {
      Styles = new List<StyleReport>();
   }

   public void AddStyle(StyleReport style)
   {
      Styles.Add(style);
   }
}

public class StoreRepository : Repository<Store>
{
    public Store Get(Int32 id)
    {
       // get store from persistence layer
    }

    // find, delete, save, update, etc.
}

public class StyleReportRepository : Repository<StyleReport>
{
   public StyleReport Get(Int32 id) 
   {
     // get style from persistence layer
   }

   // find, delete, save, update, etc.
}

And so when modifying a store's zones and adding styles, maybe something like this

IRepository<Store> storeRepository = new StoreRepository();
IRepository<StyleReport> stylesRepository = new StyleReportRepository();

Store store = storeRepository.Get(storeID); // store id selected from UI or whatever

// add a zone to the store
Zone someZone = new Zone { Name = zoneNamea }; // zone name was entered by the UI
someZone.AddStyle(styleRepository.Get(styleID)); // style id was selected from UI

storeRepository.Update(store);