Re: Aggregate or not?

"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: *[email protected]  | Connect with me
on Linkedin <http://ie.linkedin.com/in/jnicolau>

On Thu, Nov 27, 2014 at 1:28 PM, [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> 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.
>
>
>
>
>
>  
>