Design Aggregate Root Properly

Question

I have some problems designing the aggregate root. Here is how I see it in my mind :)

Store (the aggregate root)
-> Sales - A store create a sale every day
 -> Zones - A store is divided into zones
    -> Styles - A zone has x number of styles
       --> Colors - A style has x number of colors
    etc..

Now based on this my aggregate root would be the store. However if I were now to create a Repository around that, would it look something like this?

public class StoreRepository()
{
  Store GetById() {...}
  StoreZone GetZone() {...}
  List<StoreZoneStyle> GetStylesByZone() {...}
  List<Color> GetColorsByStyle() {...}
}

Is that a good way to continue? Needless to say that I am new to DDD.

Answer 1

It seems that "Store" isn't aggregate root because you don't want to hide all functionality for "Zones", "Sales" etc behind "Store" object. That way "Store" object might be very bloated.

"Store", "Zone" and "Sale" could have it's own repository.

Answer 2

I think you need to look at the aggregate boundaries and the entities as something more than just a hierarchy. Chances are, you will have a richer model than that.

The first way to tell if your aggregate is right, is that you can look at each of the entities within it and ask "Does this need to be directly accessed?" If you answer yes, then that entity is likely not a part of the aggregate.

Without knowing more about your domain, I might assume that Store is indeed an aggregate. Sales, on the other hand, are more complex. Yes, sales occur in a store, but do you have a need to look use a sale independently? If you need them outside of the scope of just working with a store, Sales is probably outside of that aggregate.

I am imagining that both Styles and Colors are immutable and repeatable, so they would likely be Value Objects in this case. Are Zones unique to a store, or do they vary?

Personally, I find value in identifying all of the items in the domain on paper (or whiteboard). I will go through a discovery phase with the stakeholder and just get them out there. Then, use these words as leaders in the conversation, trying to understand how they relate. If you interview the stakeholder well enough, the description he/she gives will actually define most of what you are looking for.

Not to beat a dead horse, but the Evans book is definitely worth getting/reading. It is a little dry, but very insightful. For a quick jumpstart, you can read the free book up on InfoQ that is basically a summary of the Evans book.