Re: Re: Populating new aggregates

"1. Any model that allows you to save your work as a draft, this means that
you need to be able to save the work as incomplete. You might be able to
save all the fields in this case, but they might not be valid."

Introduce a draft object with a method Complete which returns the actual
aggregate.

On Fri, Sep 4, 2015 at 1:42 PM, Caleb Cushing [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> I agree that aggregate should be fully populated, but it's often useful to
>> have only a projection of the aggregate. Problem is that people dislike
>> adding a new specialized type and instead try to reuse existing one. My
>> solution was to make it cheap to create a snowflake out of aggregate and
>> thus improve the domain instead of trying and shoehorning it into an
>> existing aggregate.
>>
>
> I agree in theory, but in practice there are two situations I can think of
> off the top of my head that  fully prepopulating the object graph doesn't
> work.
>
> 1. Any model that allows you to save your work as a draft, this means that
> you need to be able to save the work as incomplete. You might be able to
> save all the fields in this case, but they might not be valid.
>
> 2. Your aggregate might actually be multiple aggregate roots, take a User
> and a Role, both are Aggregates, you may have one without the other. People
> often, mistakenly, model it as User->Role instead of
> User->Roles->Permissions, thus may think of Roles as being part of the User
> aggregate. It is easy with Data Mappers to code either of these with just
> references so you can navigate them, again making them deceptively one
> aggregate. Of course an aggregate can contain another aggregate, so this is
> not wrong, however it leads you to think that the object graph should be
> complete, and it is according to aggregate boundaries you may not have
> recognized.
>
> --
> Caleb Cushing
>
> http://xenoterracide.com
>
> 
>



-- 
Studying for the Turing test