Re: Re: Populating new aggregates

Yes, I do. Real world performance hasn't been a problem yet, though our
biggest system is still not at full capacity. It also affords an extra
certainty: because I must look up any other entities by ID to use in new
(or even existing aggregates), I'm forced to (a)  verify their existence
and (b)  asset any security.

Performance isn't a problem because of, first and foremost, DB caching. We
have very well suited DB infrastructure. Most common pages are cached in
RAM and after that there is also an enormous SSD cache.

On the ORM size, we can also marked some types as cached, though we have
not yet used this tool. So if performance does start to strain, we can
enable ORM-level caching intelligently and relieve the strain.

Meanwhile, our domain is pure and consistent in always referencing full
entities.

On Tue, Sep 8, 2015, 3:32 PM [email protected] [domaindrivendesign] <
[email protected]> wrote:

>
>
>
>
>
> ---In [email protected], <trin@...> wrote :
>
> I concur that they should always be consistent. I use an ORM that can lazy
> load, so the aggregate isn't necessarily fully loaded in reality, although
> practically it is.
>
> When I create my aggregates, I always give it full objects, not id's to
> other objects.
>
>
> => So, if you don't have the full objects at hand, only the id, do you
> read the objects from database and add them to the aggregate before saving?
> Is this ok for performance?
> 
>