Aggregate or not?

"[email protected] [domaindrivendesign]" <[email protected]> 27 Nov 2014 05:28:47 -0800
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <[email protected]>
I have an example to understand the aggregate design. 
 

 The business language goes this way. I own ten restaurants. I will buy furniture from a furniture store and use them in any of the five restaurants. I will hold, assign, remove or swap furniture in the five restaurants. When I buy a new furniture, I will ask the furniture store to hold the furniture in their warehouse until I decide which restaurant I should use that. Sometimes, I don't have time to decide which furniture should go which restaurant. I will hire an interior designer to look at the furniture on hold in the furniture warehouse to decide where they should be put.
 

 Thinking about the composition, I can have a Restaurant entity  and a Furniture entity.
 

 class Restaurant
 {
 private List<Furniture> Furnitures;
 

 void BringSome(List<Furniture> furnitures);
 void RemoveA(Furniture furniture);
 }
 

 class Furniture
 {
 Restaurant Restaurant;
 

 void AssignMeTo(Restaurant restaurant);
 void RemoveFrom(Restaurant restaurant)
 }
 

 The Restaurant is a good candidate for aggregate root. It contain the Furniture. 
 

 Can the Furniture be an aggregate root too? My interior designer need to have access to the Furniture which are on hold (still in the Furniture warehouse) and not assigned to any restaurant, so a furniture can exist without it's root, but it will become part of the root only after it is assigned. I'm comparing this to Order.OrderLineItems relation. An order line item can't exist without an order. But in my example, a furniture can exist without a restaurant.
 

 Appreciate your thoughts.