Re: Re: Aggregate or not?

"Can Furniture act on it's own as entity and not as an aggregate root?"

First of all, I also agree that the first suggestion is more suitable for
the business case.
Now answering the question. Entities can be root aggregates. When an entity
is to be identified by a *global *identifier (an ID that unique in the
system) that means that the entity is a root aggregate (according to Eric
Evans book) and can be accessed globally by it's ID (using a repository).
An entity that is not root aggregate may have an identifier that is just
local and dependent on the root, therefore you only hold *temporary
references *to non-root entities. Also, whenever you need to get or make
changes to entities you should do it through the root entity, in order to
keep consistency of the aggregate. So, according to this logic, only root
entities are entitled to have repositories and that's reason enough to make
Furniture an aggregate root.


*Joao Oliveira*
*Software Engineer*

*P:* +353 831 467 299 | *E: *[email protected]  | Connect with me
on Linkedin <http://ie.linkedin.com/in/jnicolau>

On Fri, Nov 28, 2014 at 2:10 AM, [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> 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@...  | Connect with me on Linkedin
> <http://ie.linkedin.com/in/jnicolau>
>
>  
>