Re: How far do we take exposing aggregate internals?

"Jorge Branco [email protected] [domaindrivendesign]" <[email protected]> Thu, 7 May 2015 07:05:26 +0100
Newsgroups gmane.comp.programming.domain-driven-design
Message-ID <CAMfCbE_0W6dndWxz70G4PTBdFf1Ws2VWzZ+QQPp+FyfmNirpkA@mail.gmail.com>
Not really.

You just want to make sure the internal state of the aggregate roots is not
messed up by the outside world, i.e., it never gets into an inconsistent
state (a list's size() property gets out of sync with the number of
elements it actually provides). Keeping a consistent state in the aggregate
root means forbidding any other class in the system to act directly on any
internal object of the aggregate if that action may leave the aggregate in
an inconsistent state.

In this light, value types are actually pretty good things to return by an
aggregate root, since they are immutable and you just don't care how far
they get passed on into in your application, as no side-effects by its
usage will ensue.

jorge

On Thu, May 7, 2015 at 2:14 AM, Marco Paul [email protected]
[domaindrivendesign] <[email protected]> wrote:

>
>
> When trying to keep our aggregates internal structure encapsulated from
> clients (app services for example) does this imply not exposing properties
> holding value types and all behavior methods and domain events lean with
> only primitive types?
>
> Sent from my iPhone
>  
>