Re: Aggregate or not?

Thank you Joao for replying. I liked your first suggestion of making Furniture as an aggregate root.
 

 But I don't perceive your second suggestion clearly. Are you suggesting Restaurant as an aggregate root and Furniture as an entity that can work on it's own? The business scenario is that a Furniture does not have to be assigned to any Restaurant, but should expose behaviors like "Does it need a truck to deliver?" Can Furniture act on it's own as entity and not as an aggregate root?

---In [email protected], <joao@...> wrote :


 "Can the Furniture be an aggregate root too?" 

 Yes, Furniture can be an aggregate root of itself but then it needs to be stored individually and
 in that case Restaurant should not have a list of Furniture, because you wouldn't want to have the same instance of furniture in 2 different restaurants. So Furniture is also an aggregate root and should hold a reference to the ID of the Location where is hosted (restaurant or warehouse). And it's better to hold a reference to an Id (value object) than to an entity because it allows to load the entity only if you really want it (instead of loading it upfront) and it also promotes better decoupling.  
 

 Other choice could be to make the Restaurant an aggregate root that hosts a list of Furniture (on public access) and deals with it by controlling all access to Furniture, that means the no other aggregate can hold permanent access to any instances of that Furniture. You always mus pass it Only the Restaurant.can hand over a Furniture. .
 


 
 Joao Oliveira
 Software Engineer

 

 P: +353 831 467 299 | E: joao@... mailto:joao@...  | Connect with me on Linkedin http://ie.linkedin.com/in/jnicolau